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:

wskbd0->wsdisplay0
wskbd0->wsmux0

This would allow X to attach to the mux.

Question: can we get wsdisplay to use the mux like Iain wants?

    -- Garrett
> iain
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191