Bug 101993 - Support enumeration of Framebuffer devices and input devices with udev in the Framebuffer backend
Summary: Support enumeration of Framebuffer devices and input devices with udev in the...
Status: RESOLVED NOTABUG
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: low enhancement
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-31 21:11 UTC by n3rdopolis
Modified: 2018-06-04 07:10 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

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.