wayland/weston on displaylink?

[Kristian Høgsberg]

On Wed, May 02, 2012 at 02:13:37PM +0300, Pekka Paalanen wrote:
> On Mon, 30 Apr 2012 21:23:11 +0200
> Sander <wayland at humilis.net> 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