Bug 5855
| Summary: | kde keeps displaying volume-osd | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Wilfried Goesgens (willi) |
| Component: | Input Devices | Assignee: | drivers_input-devices |
| Status: | REJECTED WILL_NOT_FIX | ||
| Severity: | normal | CC: | akpm, perex, protasnb, tiwai |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.14 & 2.6.15 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
this adds a parameter, disabling the keys.
the output of dmi decode |
||
|
Description
Wilfried Goesgens
2006-01-09 01:45:42 UTC
Created attachment 6975 [details]
this adds a parameter, disabling the keys.
a patch to drivers/char/i8k.c
i used the inverse mask to have the boolean param give me either 0xFFFFF if no
param given, or a mask removing the keys in binary & operation if specified.
I hope it works properly this way, my testresults were positive.
Dmitry, is this likely to be an input big or an ALSA bug? Wilfried, you say that the bug is in 2.6.15, but that 2.6.15 was the "Most recent kernel where this bug did not occur". Please clarify. nope, it's not alsa, it's char/i8k.c. i usually don't use kde, so i got this just to know as i tried it with the actual system. i think this bug was allways there, but i just didn't notice. the driver reports key pressing, though there aren't any. sorry didn't see the not. the file states that it's from dz@debian.org, but bugzilla doesn't know him. Its not really inputnor ALSA but I will try to take care if it. Instead of module parameter though I would prefer fixing DMI tables and disable key reporting that way. Wilfried, would you mind sending me (dtor_core@ameritech.net) output of 'dmidecode' utility. Created attachment 6976 [details]
the output of dmi decode
as requested, here's the output of the utility.
Hm, we already have this signature in DMI tables. Does it say "i8k: unable to get SMM Dell signature" when you try to load the module? yep, it does say so. but it can regulate the fan though. as stated above, i load it with --force. the keys on my 8500 aren't accessed through this interface, they produce usual key events. [17200964.796000] i8k: unable to get SMM BIOS version [17200964.796000] Dell laptop SMM driver v1.14 21/02/2005 Massimo Dal Zotto (dz@debian.org) this is the reason why i thought an extra parameter should be the right way to solve this case... A DMI entry or similar would be more logical. ok, adding that goes beyound my actual scope of kernel hacking. if it works automagically, that indeed would be cooler. one shouldn't need that --force then either, right? Indeed, --force would be unnecessary then. I am not sure about pure DMI solution... We already have DMI entry convering inspiron 8500 there. Unfortunately DELL also changed BIOS interface. And it looks like 8500 has CPU and GPU temperature sensors swapped... Likely, in addition to "Product Name:", the Dell's will have a "Version" field there that could be used for determining the per-model differences. Wilfried, can you provide us with the output of 'dmidecode' on your machine? allready did. see the second atachment... Thanks. Sorry, I only was reading the emails and not the bugzilla webpage. Version: "Not Specified" in the DMI spec isn't really useful for matching. On the other hand, the system name is "Inspiron 8500". The table could probably be extended to match specifically for the "8500" and change options based on that. Any updates on this problem? Thanks. root@jordy:~# modprobe i8k [ 1724.813160] i8k: unable to get SMM BIOS version [ 1724.816494] Dell laptop SMM driver v1.14 21/02/2005 Massimo Dal Zotto (dz@debian.org) root@jordy:~# cat /proc/version Linux version 2.6.20 As this should be the prerequisite as vojtech stated (being able to load it without --force) i think no. I've turned of the kde functionality and allmost forgotten what i did way up then, plus i don't use kde usually... I think the last time i wiped my kde config the behaviour reapiered... (some months ago. I don't see any updates to i8k in the tree. Dmitry, Voitech - what's the next step, can DMI/BIOS mutations be handled in any sane way? |