Subject: Re: wsmux inject
To: Iain Hibbert <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 03/14/2006 11:42:06
Iain Hibbert wrote:
> On Tue, 14 Mar 2006, Garrett D'Amore wrote:
>> Iain Hibbert wrote:
>>> Is this 'console mux' available to inject events into, or am I doomed?
>> I saw this until I added "pseudo-device wsmux" into my kernel config.
>> You might want to verify that a MUX is configured.
> yes, I think it is - I can read the mux directly (/dev/wskbd ==
> /dev/wsmux1) but the problem (for me) is that the system is set up
> wskbd0 => wsdisplay0
> wsmux1 => ..
> whereas I wanted
> wskbd0 => wsmux1 => wsdisplay0
> in order to make injected events show up in wsdisplay0.
> I'm beginning to think though, that its hardwired that way for consoles
> and no amount of configuration will change it. Can anybody confirm that?
Yeah, I'm seeing that same thing.
I think the problem is that wskbd0 itself more or less has a mux-like
functionality in it. Looking at ukbd.c, I see
wskbd_cnattach(&ukbd_consops, sc, &ukbd_keymapdata);
So the USB keyboard driver attacheds directly to the wskbd.
It looks to me like the framework is ill-designed to support multiple
console keyboards of different kinds, but I could be missing something.
It looks like the wskbd driver than attaches to a mux, s othat you have
something like this:
This would allow X to attach to the mux.
Question: can we get wsdisplay to use the mux like Iain wants?
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191