How do you envision the API to look like? right now support for EV_SND is almost missing except to query whether the bits are present, so I'd like to know what your full requirements are here,

Actually, I'd be happy with a generic function to write events, with specified values of type, code and value. Something like:

static int libevdev_write_event(struct libevdev *dev, __u16 type, __u16 code, __s32 value)
{
	struct input_event	ev;
	ssize_t			write_len;

	if (dev == NULL)
		return -1;
	if (!libevdev_has_event_code(dev, type, code))
		return -1;

	memset(&ev, 0, sizeof(ev));
	ev.type = type;
	ev.code = code;
	ev.value = value;
	write_len = write(libevdev_get_fd(dev), &ev, sizeof(ev));
	if (write_len < 0)
		return -1;
	return 0;
}

For EV_SND, there could be something like:

static int libevdev_write_snd_bell_event(struct libevdev *dev, bool is_on)
{
	return libevdev_write_event(dev, EV_SND, SND_BELL, is_on ? 1 : 0);
}

static int libevdev_write_snd_tone_event(struct libevdev *dev, __s32 freq)
{
	return libevdev_write_event(dev, EV_SND, SND_TONE, freq);
}

well, I'm not sure the generic function is a good idea here. the kernel allows writing any event to a device but there are some minor caveats here, so I'd prefer if those that need that functionality are well aware of that and wrap it themselves.

the uinput wrappers already have that generic write function, this is where it makes sense after all.

are the EV_SND codes standardised in any way? i.e. is bell always boolean and tone always a frequency?

> the uinput wrappers already have that generic write function, this is where
> it makes sense after all.

EV_SND is not intended for sending to a uinput device, but to a kernel /dev/input/eventX device that supports EV_SND output. In my case, I'm using the 'pwm-beeper' Linux kernel driver. (Similar as for other output to input devices, namely EV_LED.)

> are the EV_SND codes standardised in any way? i.e. is bell always boolean
> and tone always a frequency?

Good question. The UAPI input.h defines SND_CLICK, SND_BELL and SND_TONE, but doesn't specify the meaning of the 'value' parameter. Nor does anything under Linux kernel Documentation/input/. I'm just going by the operation of the kernel 'pwm-beeper' driver, which uses them thus.

Quickly looking through the kernel code, it looks as though 'lkkbd' handles SND_BELL a little differently (non-zero turns it on; zero does nothing; presumably bell must stop itself after a short time). But overall, it seems that SND_BELL takes boolean and SND_TONE takes int frequency.

(In reply to Craig McQueen from comment #4)
> > the uinput wrappers already have that generic write function, this is where
> > it makes sense after all.
> 
> EV_SND is not intended for sending to a uinput device, but to a kernel
> /dev/input/eventX device that supports EV_SND output. In my case, I'm using
> the 'pwm-beeper' Linux kernel driver. (Similar as for other output to input
> devices, namely EV_LED.)

yeah, I know, that's why I'm not a fan of the generic write_event function vs a more specific write_snd function.

> 
> > are the EV_SND codes standardised in any way? i.e. is bell always boolean
> > and tone always a frequency?
> 
> Good question. The UAPI input.h defines SND_CLICK, SND_BELL and SND_TONE,
> but doesn't specify the meaning of the 'value' parameter. Nor does anything
> under Linux kernel Documentation/input/. I'm just going by the operation of
> the kernel 'pwm-beeper' driver, which uses them thus.
> 
> Quickly looking through the kernel code, it looks as though 'lkkbd' handles
> SND_BELL a little differently (non-zero turns it on; zero does nothing;
> presumably bell must stop itself after a short time). But overall, it seems
> that SND_BELL takes boolean and SND_TONE takes int frequency.

I'd say the first thing to do is to add the Documentation/ bits that specify the behaviour. Once we add a libevdev API for that I'd like it to be better defined than just  "write a value and hope" :)

> I'd say the first thing to do is to add the Documentation/ bits that specify
> the behaviour. Once we add a libevdev API for that I'd like it to be better
> defined than just  "write a value and hope" :)

I'd say just go ahead and add it, because I think this API can be reasonably inferred in the absence of explicit kernel documentation. (IMHO)

no, I don't want "reasonably inferred" because for any reasonable person there are 10 unreasonable ones that try something, find it works and then go ahead with it. So until the kernel specifies what is supposed to happen, I'm not adding this to libevdev.

Closing after over a year of inactivity, we still need the kernel to figure out what it actually wants here rather than have a "write a value and hope" policy.