evdev+hal => Too many input devices.

walt w41ter at gmail.com
Tue Jul 7 16:49:04 PDT 2009


On 07/06/2009 08:24 PM, Peter Hutterer wrote:
> On Mon, Jul 06, 2009 at 10:08:50PM +0200, Łukasz Maśko wrote:
>> Dnia poniedziałek, 6 lipca 2009, Peter Hutterer napisał:
>>> On Mon, Jul 06, 2009 at 09:26:06AM +0200, Łukasz Maśko wrote:
>>>> Dnia poniedziałek, 6 lipca 2009, Peter Hutterer napisał:
>>>> [...]
>>>>
>>>>> Please attach the whole log, this snippet is not really useful for
>>>>> finding the root of the problem.
>>>>
>>>> Here it is.
>>>
>>> urgh, not as zip file please. Always attach files to bugreports or
>>> mailinglists uncompressed - the harder you make it for someone to look at
>>> the file the lower the chances that someone does.
>>
>> Sorry, but the log file after 14 days has>200KB, therefore I didn't attach
>> it to my mail uncompressed.
>>
>>> if the file is really as long as you claim, check for add/remove devices.
>>
>> There is nothing suspicious in the part before the logs, that I've written
>> about yesterday. Besides, everything had worked till then.
>>
>>> I remember a bluetooth bug where devices never get removed, so each time
>>> the mouse connected it would be added as new device - with the old one
>>> still staying there.
>>
>> Everytime I hibernate, I stop the bluetooth susbsystem and unload USB
>> modules - required by tuxonice. So it would have been be strange, if the
>> counter was increased and not reseted while subsystem restart.
>> If I come accross this problem again I'll check, if the mouse stops working
>> under console.
>
> try exactly that then - restarting bluetooth or usb over and over again. the
> server-internal counter is at 20 (40 in git) so it's easy enough to trigger.
>
> if you're running a git server, just run xinput --create-master "foo" a few
> times to increase the number of devices already present. this way the
> the error will happen sooner.

Just wondering if lshal would also reflect the increasing number of mice?




More information about the xorg mailing list