> Following up on my own explanations:
Again ...
> Event passthrough is not even reaching ikeyd - ikeyd explicitly scans for
> the button device _only_. ikeyd needs to be fixed to search for a virtual
> keyboard and mouse device _first_, and use that if present. I can cook up
> a patch if necessa
Following up on my own explanations:
> In some mysterious way, this event passthrough does not always work. 2.6.8
Event passthrough is not even reaching ikeyd - ikeyd explicitly scans for
the button device _only_. ikeyd needs to be fixed to search for a virtual
keyboard and mouse device _first_,
> My kernel is 2.6.8-powerpc (default in sarge). Any ideas why mouseemu
> behaves in such a way?
Well, all of them need to receive events in some way. mouseemu grabs
keyboard and mouse devices for exclusive use (meaning events are not
passed on to other processes) in order to suppress the key even
Mich Lanners <[EMAIL PROTECTED]> writes:
> Hello,
>
> On 18 Feb, this message from Kirill Kuvaldin echoed through cyberspace:
>> Recently I've installed ikeyd and mouseemu debian packages.
>> It seems they conflict between themselves, so mouseemu overrides ikeyd
>> settings, i.e. ikeyd is absolut
Hello,
On 18 Feb, this message from Kirill Kuvaldin echoed through cyberspace:
> Recently I've installed ikeyd and mouseemu debian packages.
> It seems they conflict between themselves, so mouseemu overrides ikeyd
> settings, i.e. ikeyd is absolutely blocked, pressing F12 doesn't lead
> to cdrom
Hello!
I'm playing with gnu/linux on my ibook g3.
Recently I've installed ikeyd and mouseemu debian packages.
It seems they conflict between themselves, so mouseemu overrides ikeyd settings,
i.e. ikeyd is absolutely blocked, pressing F12 doesn't lead to cdrom ejecting,
and F4/F5 doesn't adjust th
6 matches
Mail list logo
