Bug 101993

Summary:	Support enumeration of Framebuffer devices and input devices with udev in the Framebuffer backend
Product:	Wayland	Reporter:	n3rdopolis <bluescreen_avenger>
Component:	weston	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED NOTABUG	QA Contact:
Severity:	enhancement
Priority:	low
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description n3rdopolis 2017-07-31 21:11:28 UTC

While Kernel mode setting is the norm for most devices that end up being the users card0, If you are going to try to go for a multiseat configuration, odds are the best way to do it as of now, is probably USB DisplayLink devices, of which although do support Kernel Mode Setting, Its harder to get them working with Kernel Mode Setting.

If it could be added, then Framebuffer devices could be added to seats, and weston could be started with --seat=seat1

Of course, you'd also need to add
SUBSYSTEM=="graphics", KERNEL=="fb*", TAG+="uaccess"

Comment 1 Pekka Paalanen 2017-08-02 13:18:24 UTC

Wasn't the input side already implemented? IIRC fbdev-backend shares the input code with DRM-backend. Maybe it's just a missing option?

I also recall some patches floating around for opening all fbdev devices rather than just one, but I think they were neglected.

In any case, if there is a choice, I would much rather see work towards making the DRM-backend work better than any enhancements to the fbdev-backend. Fbdev is dead technology.

Comment 2 n3rdopolis 2017-08-03 00:30:19 UTC

It seems to be a little different when I looked at it. ...It doesn't seem to recognizing the --seat option. 

fbdev IMHO is a good fallback, for devices such as DisplayLink/UDL or qemu's qxl. (or VirtualBox, but I haven't tried that in a while)

Comment 3 n3rdopolis 2017-09-04 15:54:10 UTC

I am trying this myself. I feel like I am almost close, (not quite there, and I need a way to make the --device option still work)

However
I am noticing that if I have a qemu system, and 3 bochs VGA devices
( -vga none -device VGA,id=video0  -device secondary-vga,id=video1 -device secondary-vga,id=video2 -spice port=5930,disable-ticketing) (and then remote-viewer spice://127.0.0.1:5930) 

and I try to start weston on /dev/fb1 manually, it doesn't turn on the screen. If I cat /dev/fb1 onto /dev/fb1 I can see the contents that weston IS running, but I guess it doesn't turn on the screen...

Comment 4 n3rdopolis 2017-09-05 01:12:14 UTC

Ok, looks like that the 
FBIOPUT_VSCREENINFO
ioctl needs to be sent. 

I can set any attribute with the fbset command, and it wakes up. Now to figure out how to get Weston to do that...

Comment 5 n3rdopolis 2017-11-19 15:50:50 UTC

I have created https://lists.freedesktop.org/archives/wayland-devel/2017-November/035878.html for this

Comment 6 Daniel Stone 2018-06-04 07:10:39 UTC

Thanks for the patches; let's track them through the list rather than here.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.