In urf-input.c, there's a line if (condition & G_IO_IN) { which needs to be if (condition & G_IO_IN & !(G_IO_ERR | G_IO_HUP)) {
This is because the actual condition passed to the function after suspend/resume and consequent new inode # for /dev/input/event4 is
(gdb) p condition $2 = (G_IO_IN | G_IO_ERR | G_IO_HUP)
i.e. we're getting G_IO_IN and error conditions signalled at the same time. The simple fix above resolves the 100% CPU issue for me and urfkill still reacts correctly to messages like in http://blog.cyphermox.net/2014/01/call-for-testing-urfkill-getting-flight.html?showComment=1390402171662#c2157211606631495090 after resume.
I'd submit a patch if I knew how :)
In urf-input.c, there's a line
if (condition & G_IO_IN) {
which needs to be
if (condition & G_IO_IN & !(G_IO_ERR | G_IO_HUP)) {
This is because the actual condition passed to the function after suspend/resume and consequent new inode # for /dev/input/event4 is
(gdb) p condition
$2 = (G_IO_IN | G_IO_ERR | G_IO_HUP)
i.e. we're getting G_IO_IN and error conditions signalled at the same time. The simple fix above resolves the 100% CPU issue for me and urfkill still reacts correctly to messages like in http:// blog.cyphermox. net/2014/ 01/call- for-testing- urfkill- getting- flight. html?showCommen t=1390402171662 #c2157211606631 495090 after resume.
I'd submit a patch if I knew how :)