On Sat, Aug 09, 2025 at 06:00:02AM +0000, yaydn@protonmail.com wrote:
> På fredag 8. august 2025 kl. 01:36, Kirill A. Korinsky
> <kirill@korins.ky> skrev:
> 
> > On Fri, 08 Aug 2025 00:59:04 +0200,
> > yaydn@protonmail.com wrote:
> > 
> > > Secondary mice and keyboards needed a
> > > 
> > > doas chown youruser:your /dev/wsmouse1
> > > doas chown youruser:your /dev/wskbd1
> > > 
> > > respectively before starting a startsway.sh, disconnecting and
> > > reconnecting these did not work until logging out and back in again.
> > > 
> > > I have these chown commands in my /etc/rc.local to have this applied
> > > every boot.
> > 
> > 
> > Why do you apply it each boot?
> > 
> > I do have:
> > 
> > ~ $ cat /upgrade.site
> > [...]
> > echo Recover access to webcams for user catap
> > echo 'chown catap /dev/video*' >>/etc/rc.firsttime
> > 
> > [...]
> > ~ $
> > 
> > which rewert access after each upgrade.
> > 
> > --
> > wbr, Kirill
> 
> For a lot of stuff, using the ttyC0 or the first tty is sufficient, but
> secondary mice, keyboards, and webcams need chown reapplied at some
> point. You might be right that it only needs to be after sysupgrade's
> and that /etc/rc.firsttime is more than sufficient. I specifically
> automated the chowning with /etc/rc.local as my touchpad is wonky and
> need a secondary mouse.
> 
> I could be wrong though. As long as the user can access the
> /dev/dri/card0 or whichever gpu and input before startsway.sh starts I
> think you are okay. mathieu@, volker@, or someone actively working on
> the guts of the graphical components in base is probably the one to ask
> for the current interactions of security, wlroots based compositors, and
> what is default provided by ttyC0 and which settings to change if you
> want to use another ttyC#.
> 
> I don't have a webcam, so I can't fully comment, but I think you can
> chown that after startsway.sh, like a cd/dvd/bluray drive or rsd#c of a
> usb drive for qemu raw access or the like.
> 
> The secondary or tertiary and so on input need user access prior to
> startsway.sh, as they do not yet have hotplug in wlroots based
> compositors (window managers[WM] or desktop environments[DE]) on
> OpenBSD. Sway and other wayland compositors will fail to start if they
> cannot access the gpu with the user level permissions.
> 
> I'd be happy to be wrong. For all I know there is some greeter in wip or
> my experience dogfooding has been superseded by some advancement or is
> woefully incomplete.
> 
> I hope this info is helpful to some experimenting with wayland on
> OpenBSD. Someone more qualified might correct any erroneous notions.


Check out fbtab(5). This is the mechanism use to change ownership of
the /dev/entries when someone logs in on the console.
It cans be customized to give access to more devices if needed.

Currently in the libinput-openbsd port I've choosen to use invividual
input devices (/dev/wskbd0, /dev/wskbd1, /dev/wsmouse0,
/dev/wsmouse1,...)  to access the devices, so you need to tweek fbtab
to get access to extra devices.

This can be seen as a hack, as the mux devices (/dev/wskbd and
/dev/wsmouse) should be enough to provide access to all input devices.

Currently, there is some missing information in the events returned
by wsmux(4) for libinput to work correctly. I've worked on that
recently and I've code that works for multiple keyboards and multible
relative pointer devices (mouses, trackpad,..). Aboluse pointing
devices (tablets, touchscreens,...) require more work in libinput.

Xorg works around those issues in 2 (bad) ways that we'd like to avoid
with wayland:
- for multiple keyboards it uses the WSDISPLAY_COMPAT_RAWKBD kernel
  option to re-encode keyboard events in the kernel to PC-AT
  compatible keycodes which are the same for each keyboard. This
  option adds code that ihmo don't belong to the kernel (and requires
  new transcoding tables in the kernel for each new type of keyboard
  encoding).
- for pointing devices, X takes adavantage of the fact that it has a
  privileged helper process to open /dev/wsmouse<n>, even whithout an
  fbtab entry for it, to attach a specific X input driver to devices
  that are more than just a relative pointer (handled by
  xf86-input-ws(4)). Wayland runs with no elevated privilgedes, so
  this is not possible.

Also the lack of connect/disconnet events for input devices cause
issues whith suspend/resume, where USB connected devices (and some i2c
connected devices too) get disconnected on suspend and re-attached on
resume. The order may change, making some devices unusable. The
changes to wscons(4)/wsmux(4) that I'm working on should help with
those issues too, making Xorg and wayland able to correctly configure
each input device as it gets (re)attached to the kernel.

I'll clean up my patches and send them for review in the coming days. 
-- 
Matthieu Herrb