Date: Thu, 23 Jun 2005 21:40:06 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: marcel@xcllnt.net Cc: freebsd-current@freebsd.org Subject: Re: request for comments: kbdmux(4) (long) Message-ID: <20050623.214006.22018233.imp@bsdimp.com> In-Reply-To: <20050623201244.GA4184@ns1.xcllnt.net> References: <42BAFE37.4080504@savvis.net> <20050623201244.GA4184@ns1.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20050623201244.GA4184@ns1.xcllnt.net>
Marcel Moolenaar <marcel@xcllnt.net> writes:
: On Thu, Jun 23, 2005 at 11:23:51AM -0700, Maksim Yevmenkin wrote:
: >
: > - kbdmux model: kbdmux(4) is "super-keyboard" driver that consumes input
: > (raw scancodes) from slave keyboards. the side effect is that _all_
: > keyboards attached to the kbdmux share the _same_ state. basically user
: > can press ctrl on one keyboard and "C" on another keyboard and it still
: > will work. is that good enough?
:
: I think one can argue both ways. Personally I think shift states should
: be kept private to the keyboard. However, when processes are given
: access to led- and shift states and are allowed to modify them, then
: per-keyboard state doesn't pan out. Not unless the API has support for
: multiple keyboards. So, go with what makes sense for this particular case.
: Chances are that what you have now is already the most sensible, even
: if it's not exactly "right".
This is as right as we can get with our current model. If we're
really mapping everything into one keyboard, I think it is the best we
can do for now. It is also likely 'good enough' from a user point of
view so long as the following works:
Press control on kbd0
Press control on kbd1
C should produce ^C
Release control on kbd0
D should produce ^D
release control on kbd1
E should produce E.
But I'd not hold up integrating it if this edge case doesn't work, so
long as it doesn't crash the system...
: > - kbdmux(4) switches all keyboards into K_RAW mode, so if kbdmux(4) is
: > the default keyboard then perhaps all keyboard drivers could be
: > simplified and just return K_RAW scancodes?
:
: Yes, if kbdmux(4) becomes default and non-optional, then it makes sense
: to simplify and refactor. This would also be beneficial for the syscons
: replacement I'm writing.
The key here is 'and non-optional'. It might make sense for kbdmux(4)
to keep doing this through the transition period.
I think it must remain optional, however. It is useful to have
multiple keyboards on machines that do not map into one. I've setup
machines in the past with two video cards and two keyboards to have a
two person workstation. It is also useful in certain embedded systems
to allow similar things (since there are USB keyboard devices that
produce ascii output, and you need to know which of the keyboard
devices generated the sequence to know what the user actually did).
: > - if kbdmux(4) is not default keyboard then what syscons(4) should do?
: > - should kbdmux(4) go into 6.x?
:
: I would say: yes. It's an open issue for a while and it's good to
: get it closed. It's one of those topics that hardcore developers may
: not care too much about, but which is highly valued by the average
: user.
I'd put it into 6.0 even. I'd make it default during the beta
releases. If there are issues, we turn it off by default for 6.0 and
then early adapters can turn it on and the bugs can be worked out.
For 6.1 we can reverse the default if there'd be no user visible
changes from doing that for the typical user. 'Special needs' people,
like I give in the example above, are in the vast minority and will be
sophisticated enought to know what to do.
The above assumes that all the /etc/rc goo, if any, can be worked out
in time.
I'm not the re@ and don't speak for them. The above is my two cents.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050623.214006.22018233.imp>