xf86-input-evdev-1.2.0 broken

[Thomas Ilnseher]

> Thx! I see. It actually would be weird to apply a patch to the main kernel 
> branch.
> 
I see some sarcasm ;)
> Thomas, don't you think it's unnormal to patch a kernel to make evdev working 
> stable?  

I think it's unmoral to apply crap patch to the kernel ;)

ok, I'm at home right now, so here is the patch. please note that I've
already sent it to the hid maintainer.

Anyway, you can clearly see that the patch is crap:

I had no clue what that "bits" stuff is doing, and what for these
map_*_clear functions are. So I invented a new return code (2), and
added a "goto ignore" to the hidinput_mapping function.

That is bad style, and i guess this patch won't be ever applied to the
kernel. I sent it to the maintainer in the hope that he will correct
these obvious bugs, and maybe give me some insight how things work.
Right now I'm waiting on an answer, but maybe the mail got forwarded
to /dev/null.

there is another thing here: the consumer.hwheel . the mouse obviously
has none. BUT it is still reported. I added some code to ignore this
wheel. 

But there might exist a mouse with the same vid:pid that actually has
such a wheel (both mouses might share the same electronics, only the
physical wheel and the led/photo diodes are missing on mine).

my patch would render this other mouse nonfunctional.

btw, 0x0a5c is the vid of broadcom ;) so this might affect quite a few
mouses.

Thomas
-- 
Thomas Ilnseher <illth at gmx.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hid-quirk-trust15351.diff
Type: text/x-patch
Size: 1717 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20080601/11dc9e70/attachment.bin>