for such situations, events issued on the same device type, same device
number, same event type and same event index should always have slightly
different times, just in case. like 1/65536th of a second later,
artificially. no?
> > Which would you go for? Myself I would choose either 3* or 2*.
> I'd go for 4. We want to provide _lots_ of room to grow. Remember when
> 640k was enough for anybody? I think here 64k will do, but 256 is a bit
> short. (Yes, the current keyboard driver gets away with 128.)
and the current PC video cards disallow use of several video cards at
once, except in very special situations (2 if one is MDA/Herc)
> > I think that both offer quite enough of axes and buttons.
> I thought that we were talking about not joining the number+value for
> buttons here. If you do, then it is enough, I think.
the doc i've written says 64 absints, 64 relints, 16384 bools. and there
is always the special event type, and i've extended the event-type field
to 4 bits. This is subject to debate and change.
> But we don't know the label on the keyboard unless sombody tells us -- you
> can't tell an azerty from a qwerty programaticly.
ioctl() or special output event.
> Even worse -- \` can be a "backquote", an "acute accent" a "negitive-slope
grave, not acute.
> accent", or several other things in several languages that I can't even
> pronounce. Also, userspace might not care about what the fourth key on the
> top row is unshifted, but shifted -- a dollar or a pound?
shifts don't come into account here. so you don't say '#', but '3'. we're
talking about scancodes. if an application wants to know this, it should
read the tty device instead, or in extreme cases use compiled xkb maps or
something like that. no? (i'm not too sure)
matju
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu