> My proposal is to remove the exclusive open, and instead put a qlock
> around the loop which sends codes from kbin to kbd.
or, keep a small structure, perhaps in the channel to keep
track of these things. there's also a limitation where the same
kbmap gets applied to all keyboards.
- erik
No objections having been raised, I've submitted a patch
(mousein-non-exclusive) to remove this restriction.
Next, the same question about /dev/kbin - does that need to be
exclusive open? I think not. Slightly more complicated, because
kbin can receive a pair of inputs (escape + scancode) and pa
> can't think of any. one can already attach 2 mice to a pc,
> one ps/2, and one usb. it works fine.
I second that, I've had a ps2 mouse and a serial trackball working
side by side.
++L
On Mon Dec 10 11:37:12 EST 2012, 9f...@hamnavoe.com wrote:
> Is there a good reason to forbid multiple processes to open
> the mousein device? I can't think what trouble it could cause
> (writes have to be atomic anyway because the driver will only
> parse a complete input), and it makes it awkwar
Richard Miller <9f...@hamnavoe.com> once said:
> Is there a good reason to forbid multiple processes to open
> the mousein device? I can't think what trouble it could cause
> (writes have to be atomic anyway because the driver will only
> parse a complete input), and it makes it awkward to debug
>
Is there a good reason to forbid multiple processes to open
the mousein device? I can't think what trouble it could cause
(writes have to be atomic anyway because the driver will only
parse a complete input), and it makes it awkward to debug
a new mouse driver if a usb mouse is already (or has eve
