Arch Linux

I have the same keyboard combo and for me they also both stopped working after the update to version 158.

After a little bit of searching on the internet I found out the problem was the 70-hid2hci.rules file so I compared the file of udev 157 and udev 158 and found out it was using the hidraw interface in version 157 for all Logitech devices, but in 158 there was also a check on the productId which made it choose between hiddev and hidraw. So obviously this switch went "wrong". After changing some things a bit (the productId check) both my keyboard and mouse work fine again.

After you've installed the 158 update you can patch the /lib/udev/rules.d/70-hid2hci.rules file using the attached patch file and everything should work fine again.

Ps. I'm a little bit new to this, but does anybody know how to get this officially fixed in Arch and a way to get this bug/patch upstream to the udev developers? I cloned the git repository of udev and traced back the breaking commit which states the switch is because hiddev doesn't work for other Logitech devices and the default should be hiddev expect the devices which don't work using hiddev and only work using hidraw, which obviously is the case for this keyboard and mouse combo. So this patch is "the right one" and now I'm looking for a way to get it upstream.

158 breaks my Logitech Dinovo Media combo.
Roberts patch did not work for me.

Please send the patch to linux-hotplug mailing list ( linux-hotplug@vger.kernel.org ). Thanks.

"158 breaks my Logitech Dinovo Media combo.
Roberts patch did not work for me."
Can you post the product id of the keyboard and mouse? When you've got the keyboard and mouse working you can find the product ids in /proc/bus/input/devices (the Product=??? above the Name="Logitech ..." line) Then I will add them to the patch and post a new patch (and mail it to the linux-hotplug mailinglist)

Should be c70b (kbd) and c70c (mouse), output attached.

Could you try the attached patch? When it works I will send in the patch to the udev developers.

The udev.patch works for me, good job (much better than udev devs :D ).
Btw, i wonder how many more logitech devices are broken in 158 ... we probably havent found em all (http://www.linux-usb.org/usb.ids).

"Btw, i wonder how many more logitech devices are broken in 158 ..."
There are (and were, in 157) only eleven devices listed, of which now five are confirmed working (four from this bug report, and one which was already there). So there are only 6 left and some of them still have to be working (otherwise 158 didn't break our combos, because between 157 and 158 they kind of reverted a change from between 151 and 152 because from 152 on other combos where broken)

And I have just send in the patch to the linux-hotplug mailinglist so hopefully it'll be fixed in 159.

Hmm, you should have CC'ed me on the post to the ml. Can you provide an archive link for it?

<rant on>
I am surprised how things like this can slip through a udev release, if you change something you have to test it (logitech devices were obviously not tested) .. but testing in the open source world is obviously not very popular. One happy hacker changed logitech stuff and didnt even bother to get it tested by people having the hardware before release.
I wish the persons being assigned this ticket would have taken some interest earlier ... no keyboard is a pretty serious problem.
</rant off>
admins, feel free to remove this irrelevant comment

No developer has a hardware lab with all possible hardware devices.

"Hmm, you should have CC'ed me on the post to the ml. Can you provide an archive link for it?"
As I said, this bug fixing "thing" is all new to me, so sorry for this (beginners) fault. I also don't know what an archive link is. To get not too much offtopic you can contact me by email and I will give you the info you'll need.

Tobias, of course no ONE developer has that.
Since udev is a very central and important component they should have some test procedure (beta requesting testing of certain changed things).
I wish that arch could have some better quality assurance to avoid some bad bugs from upstream, but i guess so few are running testing so this will probably never be a reality.

Hrm the Changelog states only bugfixing, I will not check every single git commit they do.
The package was in testing and i got the signoffs, that's the way how arch handles things.
I can only encourage people to use testing and report bugs quickly if something is not working as expected.

You can keep ranting all you want. The development procedure on Arch is always the same: A critical package is put to the testing repository. A signoff email is sent to the public development list. If there are no user or dev complaints within a few days and a number of devs sign off on the new package, it is moved. It is entirely impossible for us to test all possible scenarios - users with strange hardware have to report problems to us, period.

However, if you want to donate one of your keyboards to me, I can ensure it'll never fail again, and I would have a fancy new keyboard.

If you want to ensure that your hardware is going to work with the new udev, you have to test the new package and report problems while it is still in testing. Furthermore, we ship the udev rules mostly unmodified from the upstream udev code - where this issue hasn't been fixed apparently: http://git.kernel.org/?p=linux/hotplug/udev.git.

The above fix has been sent to linux-hotplug: http://marc.info/?l=linux-hotplug&m=127827205608056&w=2 and we can push a bugfixed version of udev to our repositores now.

Tobias,
I dont blame you, no way you could have known about this upstream bug.
I have only found one other report about this problem, the person was running debian unstable and posted about the problem yesterday (4th of July).

Thomas,
I am tempted to send you my crappy hardware and buy something fancier .. but i will stick to it a little longer :).
The dev procedure sounds good and i understand upstream bugs like this is hard to catch. I can only hope arch gets even more popular and more people runs testing.
My rant was really aimed at udev devs, i tried to hold back but failed .. i will try harder in the future :).

The same as for us holds for the udev devs - they rely on distributions to find problems in their releases ... it is a process that so often fails.

Anyway, Tobias, should we apply the patch from http://marc.info/?l=linux-hotplug&m=127827205608056&w=2 (the same that Robert posted above) to our udev package? It seems pretty likely that Kay will eventually apply this patch to upstream udev.