On Wed, May 02, 2012 at 02:13:37PM +0300, Pekka Paalanen wrote: > On Mon, 30 Apr 2012 21:23:11 +0200 > Sander <[email protected]> wrote: > > > Hello All, > > > > Would it be possible to run weston on a displaylink device? > > > > I compiled a 3.4-rc5 kernel with: > > > > x301:/usr/src/linux-3.4-rc5# grep DRM.*=y .config > > CONFIG_DRM=y > > CONFIG_DRM_USB=y > > CONFIG_DRM_KMS_HELPER=y > > CONFIG_DRM_UDL=y > > > > And get a text console on a Samsung Syncmaster 2243qw, connected to an > > Openrd-client with Debian Sid/experimental. > > > > Executing 'weston 2>weston.error' on that console gives a frozen screen > > without clearing it (so all previous types text is there). > > > > 'weston.error' contains: > > no drm device found > > failed to create compositor > > > > > > As far as I understand, a displaylink device would be the only possible > > way to get weston running on an arm device, as arm gpu's are hardly > > supported with opensourcesoftware, correct? > ... > > [ 13.753569] usb 1-1.7.2: new high-speed USB device number 5 using > > orion-ehci > > [ 13.888682] usb 1-1.7.2: New USB device found, idVendor=17e9, > > idProduct=0102 > > [ 13.895785] usb 1-1.7.2: New USB device strings: Mfr=1, Product=2, > > SerialNumber=3 > > [ 13.903300] usb 1-1.7.2: Product: Samsung UbiSync Monitor > > [ 13.908744] usb 1-1.7.2: Manufacturer: DisplayLink > > [ 13.913564] usb 1-1.7.2: SerialNumber: 0102-HVNS40102800000 > ... > > [ 21.180430] udlfb: DisplayLink Samsung UbiSync Monitor - serial > > #0102-HVNS40102800000 > > [ 21.188316] udlfb: vid_17e9&pid_0102&rev_0001 driver's dlfb_data struct > > at df23e000 > > [ 21.196030] udlfb: console enable=1 > > [ 21.199535] udlfb: fb_defio enable=1 > > [ 21.203118] udlfb: shadow enable=1 > > [ 21.208383] udlfb: vendor descriptor not available (-32) > > [ 21.214146] udlfb: allocated 4 65024 byte urbs > > [ 21.304242] udlfb: 1680x1050 @ 59 Hz valid mode > ... > > [ 21.401988] udlfb: 1440x900 @ 75 Hz valid mode > > [ 21.406462] udlfb: Reallocating framebuffer. Addresses will change! > > [ 21.419758] udlfb: 1680x1050 @ 59 Hz valid mode > > [ 21.424335] udlfb: set_par mode 1680x1050 > > [ 21.472623] udlfb: open /dev/fb0 user=0 fb_info=df0e8c00 count=1 > > [ 21.478927] udlfb: set_par mode 1680x1050 > > [ 21.565854] udlfb: set_par mode 1680x1050 > > [ 21.631706] udlfb: DisplayLink USB device /dev/fb0 attached. 1680x1050 > > resolution. Using 6896K framebuffer memory > > Hi, > > do you actually have a /dev/dri/card* device file, or > only /dev/fb0? > > Weston DRM backend needs /dev/dri/card*, because it wants to initialise > a GPU for rendering, not just for display. > > As a thought, if you don't have a GPU, you might use software rendering > and push the pictures out through the USB device, but I don't think sw > rendering is implemented for the Weston DRM backend. The backend very > juch assumes it can use GBM to allocate GPU-accessible buffers, and > that gets tricky if you have no usable GPU. > > In my mind the solution would probably be to write a new Weston backend > for using the DRM KMS APIs with dumb buffers and somehow make llvmpipe > to work with that. Wait, does llvmpipe even support ARM yet... Or maybe > make GBM work with soft/llvmpipe? Dunno. > > In any case, without a real GPU, the performance will probably suck. > Maybe the best would be to write a specifically software rendering > compositor, for instace using pixman, if there's no way to use a GPU.
Yeah, I think pixman is the best answer to the sw render case, it's just a little tricky to figure out how to cut the cake without making weston even harder to work with. It would be pretty interesting to see though,and I think the rendering can be abstracted without impacting the readability of the code too much. Kristian _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
