On Sun, 24 Nov 2024 08:30:03 +0100
Matthieu Herrb <matthieu@herrb.eu> wrote:

> On Fri, Nov 22, 2024 at 07:38:06PM -0500, Thomas Frohwein wrote:
> > On Wed, 20 Nov 2024 21:52:03 +0100
> > Matthieu Herrb <matthieu@herrb.eu> wrote:
> >   
> > > > +
> > > > +#define UJOYIO_RUMBLE	_IOW('J', 7, struct ujoy_rumble)
> > > > +    
> > > 
> > > Doesn't the '_IOW()' here mean that you need write access to
> > > /dev/ujoy/<n> to use that ioctl() ?  
> > 
> > While a little out of my depth, I've had some discussions and based
> > on that and also [1], the choice of _IO{W,R,WR}() depends on if a
> > struct is sent (written) to the kernel and/or read.
> > 
> > The filesystem permissions for /dev/ujoy//<n> are for open(2) calls,
> > but ioctl(2) is different. For what it's worth the implementation
> > in my diff works fine without any write access, which appears to
> > prove this..  
> 
> I'll let other comment on this. It's not clear in my mind either where
> the boundary should be. But note that with your patch and the current
> permission model, any user can make your joystick vibrate.

That is true. While I can't dismiss a potential for misuse, it seems
hard to picture a rogue process making the gamecontroller vibrate and
the risks seem small.

Do you have an alternative in mind for managing write operations,
something that I could look at to address the concerns? I see for
example audio(4) devices that are only accessible by root or _sndiop
and so the sndio system takes care of it via sndiod to my understanding.

The initial ujoy(4) took inspiration from fido(4) in how it builds on a
subset of the uhid(4) operations. Note that compared to fido(4)
devices, /dev/ujoy/N don't have write permissions so the ioctl would
only add a very specific write operation rather than arbitrary ones.

> 
> >   
> > > 
> > > Also, even though I'm partly responsible for the current
> > > situation as porter of the now defunct ISA joy(4) driver
> > > (https://man.openbsd.org/OpenBSD-3.0/i386/joy),  I think one should
> > > think about plugging it into wsmouse(4) (adding a
> > > WSMOUSE_TYPE_JOYSTICK to let applications make the difference). IT
> > > will make supporting them in libinput-openbsd easier.  
> > 
> > This would seem to me like a large project, and how much need is
> > there for joystick devices as part of wsmouse? The joystick/gamepad
> > uses that I'm aware of are 99% via sdl/sdl2 and that doesn't have
> > problems with using working via /dev/joy or /dev/ujoy...
> > 
> > Also that's not specific to the question of enabling the
> > rumble/force feedback support for the ujoy(4) device that we
> > already have, right? 
> Yes that's a more general comment, and a much wider project. 

Would an integration into wsmouse address the concerns about global
access to the vibration control? I am not familiar with the wsmouse
internals, but with a hint where to start could explore this...