wayland/weston on displaylink?

Pekka Paalanen ppaalanen at gmail.com
Wed May 2 04:13:37 PDT 2012


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.

FWIW, I have Weston running on ARM with proprietary GPU drivers:
http://ppaalanen.blogspot.com/2012/04/first-light-from-weston-on-android.html


HTH,
pq


More information about the wayland-devel mailing list