Date: Thu, 23 Jun 2005 15:25:16 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-current@freebsd.org Subject: Re: request for comments: kbdmux(4) (long) Message-ID: <20050623222516.GA4746@ns1.xcllnt.net> In-Reply-To: <42BB2339.8050101@savvis.net> References: <42BAFE37.4080504@savvis.net> <20050623201244.GA4184@ns1.xcllnt.net> <42BB2339.8050101@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 23, 2005 at 02:01:45PM -0700, Maksim Yevmenkin wrote:
> >
> >make that non-i386...
> >
> >This won't be useful on ia64 because syscons doesn't work there and
> >I don't plan to try to makee it work there ever. I'm working on a
> >replacement where the multiplexing of the keyboard (as well as the
> >graphics adapter) is inherently part of the framework. In particular,
> >the user will be able to control how input and output devices get
> >multiplexed and/or untied into seperate consoles. This all goes beyond
> >what you're doing, so don't worry about it.
>
> great. would this eventually replace syscons(4)/pcvt(4)/etc. on all
> supported platforms? or will it always be non-i386 console code?
I'll make it machine independent, but only enable it for ia64.
Pretty much what I did with uart(4). Other platforms can adopt it
and I'm willing to invest on technical matters to make it work, but
I'm not going to waste time in political discussions trying to make
that happen for all platforms. I hope that alpha, sparc64, powerpc
and arm will benefit without there being any significant downsides,
so that adoption would be easy enough. I doubt i386, with its large
userbase and established interfaces, is likely to switch away from
syscons. I'm not even sure we should try. We always could, but then
there needs to be agreement across the board and my involvement on
the political battleground would not be pivotal. Nor would the work
involved in actually making it happen be solely on my plate.
> >>- should kbdmux(4) be merged with kbd/syscons and used by default?
> >
> >I think that would make sense, given that syscons is pretty much
> >single-head.
>
> ok
>
> >>- 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.
>
> ok
>
> >>- if kbdmux(4) is not default keyboard then what syscons(4) should do?
> >>look for "kbdmux" keyboard first and the look for any ("*") keyboard?
> >
> >This quickly gets complex. I would say that if kbdmux(4) is configured
> >into the kernel, it will always be used. The question is whether kbdmux
> >should be optional or not.
>
> as a transition plan i was thinking about changing syscons(4), so it would
>
> 1) (a) have a hint to which keyboard (or keyboards) it should to use by
> default or (b) always try "kbdmux" first then any "*" keyboard
>
> 2) if syscons(4) found "kbdmux" keyboard (because kbdmux.ko was loaded
> from the loader.conf or compiled into kernel) then it would scan all
> available non "kbdmux" keyboards and add them to the kbdmux.
>
> the above two steps should be performed on boot and/or when syscons(4)
> detects no active keyboard.
>
> >>- what kbdcontrol(8) behavior should be? should it be smart enough to
> >>recognize if current keyboard is kbdmux and behave differently?
> >
> >That depends on whether there's anything special or different it needs
> >to do. Since your question seems to imply it does, could you explain
> >how, where and why?
>
> right now when usb keyboard is attached devd(8) calls kbdcontrol(1) and
> tries to switch active keyboard.
Ah, yes. I hate that :-)
> if kbdmux(4) is active the usb keyboard
> should be added to the mux - not switched.
For some reason I think it's better to not go through devd. Just
handle it in the kernel. With kbdmux(4), switching keyboards is
nonsensical, so devd should stop doing that. This doesn't mean
that devd shouldn't be notified, of course.
> in the same time, it is still
> might be desirable to really switch keyboards, i.e. between kbdmux and
> say wired ps2 keyboard that is not in the mux.
As I said: this quickly becomes complex. I would suggest to keep it
simple. Make it an all or nothing proposition. Flexibility is good,
but before you know it you'd be better off redesigning the console.
What a coincidence: I'm doing that as we speak :-)
> so, i was thinking to change kbdcontrol(1) so it would
>
> 1) when -k (add/switch keyboard) option is given check if the current
> keyboard is kbdmux the add keyboard to the mux, otherwise switch keyboard.
>
> 2) provide a new option to kbdcontrol(1) that would _really_ switch
> keyboard (no matter if current keyboard is kbdmux or not)
>
> 3) -K (disconnect keyboard) with kbdmux should either be (a) noop or (b)
> delete keyboard from the mux. i kinda like (a) because user must specify
> keyboard index to disconnect in (b) and this is yet another api change.
> on the other hand it might be desirable to disconnect keyboard from the
> must without detaching it (another new option?)
>
> now, another case is when keyboard is disconnected. in this case devd(8)
> calls kbdcontrol(1) and tries to switch keyboard to kbd0
> unconditionally. in theory this could work (if kbd0 is kbdmux), but may
> be its better to have default keyboard syscons(4) hint and then use
> kenv(1) to fetch it and have kbdcontrol(1) use it.
>
> does this make any sense?
It doesn't sound unreasonable. I think it could be made to work, but I
fear to think about the ways it could fail to do the right thing.
One way to approach this problem is by summing up the different scenarios
we can run into, describe how we want FreeBSD to behave in those scenarios
(ideally), determine how much work it would be to implement the ideal
behaviour and then see if it's worth it. If not, then a reasonable and
cheap alternative should be looked for -- if one exists.
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050623222516.GA4746>