| Summary: | app-misc/hddled seems to cause keyboard problems | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Blake Leverett <bleverett> |
| Component: | Current packages | Assignee: | Michael Weber (RETIRED) <xmw> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | bleverett, jer |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Flipping a LED on and off that is obviously not designed to support that over a data bus that is obviously not designed to handle that use of bandwidth - that can have side effects like the bus failing to promptly deliver data. It's nothing more than a funny hack and nobody guarantees that it works on every system. Having said that, you could fix the bus or fix the refresh interval - updating less often should decrease the load on the bus. Hello Blake, I experience the same problems on my notebook (thinkpad x61, i8042 keybaord), but haven't thiught of xhddled being the problem. Actually it shouldn't run on there, having an hddled between keyboard and screen. I'm gonna test it with reduced update rates and will change the default and/or add en elog warning. Thanks for the report. Michael (In reply to comment #2) > Having said that, you could fix the bus or fix the refresh interval - > updating less often should decrease the load on the bus. Fair enough. I didn't expect the Gentoo devs to fix the upstream problem with hddled. I reported it here because the hddled package is a single C file with no way to report bugs, so at least the problem is documented here. Hopefully others out there may notice where the problem is and fix it. I do notice that the problem is way worse on my home machine, which is much faster and has more memory and processors (6 vs. 4) than my work machine, where the problem is quite rare. So I don't think it's a speed problem. It may have something to do with running openbox on my home machine, since that interacts with the keyboard. In any case, if there's a better place to discuss this bug than Gentoo bugs, let me know and I'll post it there. I think the person "foonly" can be reached thru the forum http://forums.whirlpool.net.au/archive/619126 The user might be still active there, since http://members.optusnet.com.au/foonly/whirlpool/code/?C=M;O=A was last touched Feb24 this year. Another discussion about the functionality: http://bytes.com/topic/python/answers/575125-interacting-keyboard-leds ledcontrol and a collection related software (for linux) http://sampo.kapsi.fi/ledcontrol/ I definitely like the functionality, maybe we can improve hddled or find an better solution. I didn't find any other distribution providing this package, so this place might be quite right. (In reply to comment #4) > (In reply to comment #2) > > Having said that, you could fix the bus or fix the refresh interval - > > updating less often should decrease the load on the bus. > > Fair enough. I didn't expect the Gentoo devs to fix the upstream problem > with hddled. I reported it here because the hddled package is a single C > file with no way to report bugs, so at least the problem is documented here. > Hopefully others out there may notice where the problem is and fix it. > > I do notice that the problem is way worse on my home machine, which is much > faster and has more memory and processors (6 vs. 4) than my work machine, > where the problem is quite rare. So I don't think it's a speed problem. It > may have something to do with running openbox on my home machine, since that > interacts with the keyboard. > > In any case, if there's a better place to discuss this bug than Gentoo bugs, > let me know and I'll post it there. Oops, I meant VirtualBox, not openbox. VirtualBox seems to make the problem worse, such that the control key appears stuck down, and I have to press control a bunch of times to be able to type non-control characters. (In reply to comment #4) > I do notice that the problem is way worse on my home machine, which is much > faster and has more memory and processors (6 vs. 4) than my work machine, > where the problem is quite rare. So I don't think it's a speed problem. It > may have something to do with running openbox on my home machine, since that > interacts with the keyboard. As I said before, the problem is in the keyboard and its data bus, which are not designed to handle this information flow. Your faster computer may just have a keyboard less well suited, because the ways hddled uses it lie outside the design specifications. |
I installed hddled on two computers. One is AMD64 and other other is Intel(R) Core(TM)2 Quad CPU. In both cases, the hddled program did nothing, but the xhddled program worked. The scroll lock led mirros the HDD led. The problem is that I see keyboard problems on both computers running hddled. Occasionally keyboard characters are missed, and also occasionally (about once/hour) a single keypress ('x') produces a long string of chars from the keyboard('xxxxxxxxxxxxxxxxxxxxxxxxx'). Reproducible: Always Steps to Reproduce: 1.Install hddled, run it 2. Verify that keyboard LED is working. 3. Do some work for a few hours while hddled is running. Actual Results: Missed keypresses, runaway keypresses ('sssssssssssssss' from one keypress) Expected Results: Keys pressed are recognized once only. Nothing yet. It's not that big a deal but I love the hddled functionality, so I want it to work without any problems. Thanks.