Dell XPS M1330 volume keys as pressed two times

Bug #310270 reported by Ciso
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
KDE Multimedia
Invalid
Medium
xserver-xorg-input-evdev (Ubuntu)
Incomplete
Low
Unassigned

Bug Description

All my volume multimedia keys (vol-up, vol-down, mute) works bad on my Dell XPS M1330 on Kubuntu with Kde4.2 beta.
Every keys works as if it was pressed twice, so i raise up my volume by two levels, and when I mute the volume, it mutes and than unmutes.
Sorry for my english. If you need more information, ask me.
Everything was working good on Gnome.

Tags: kubuntu
Revision history for this message
In , Ciso (cisoprogressivo) wrote :

Version: (using Devel)
OS: Linux
Installed from: Compiled sources

On my Dell XPS M1330 my multimedia keys work as its are pressed twice.
e.g. if I pressed volume up, the volume raise of two values.
If I pressed mute, the volume mute and the unmute.
Sorry again for my english

Revision history for this message
In , FiNeX (finex) wrote :

Which revision are you using?

Revision history for this message
In , Ciso (cisoprogressivo) wrote :

I use Kubuntu 8.10 updated via "official" KDE's repo.
So it's the version included KDE 4.1.85.

Revision history for this message
In , Aldoo (aldo-public) wrote :

I must say I've been seeing this since I use KDE 4(.0) on my current laptop, and that it still does this in 4.2 beta.
I never reported this because I tought of a hardware support problem (you know, the ACPI mess... ).

I am using OpenSuse packages for my part and my laptop is a Dell XPS M1330 too.
… and well, volume keys are detected as pressed, not only twice, but three times!

Sorry for this "me too" report, but I hope this will help finding the cause (I believe it is lower level than KDE, though… ).

Revision history for this message
In , Christian Esken (esken-kde) wrote :

You could try to use "xev" to see how many keys are pressed. But make sur you quit KMix before running xev, because otherwise KMix might steal the KeyPress- and KeyRelase-Event of the volume keys.

Revision history for this message
In , Ciso (cisoprogressivo) wrote :

I tried, and in effect it works like pressed 4 times!!
There's not a "rule". Sometimes, it works like pressed twice, 3 times or 4 times.

Xev output:
KeyPress event, serial 31, synthetic NO, window 0xa00001,
    root 0x13b, subw 0x0, time 770563, (729,598), root:(734,623),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0xa00001,
    root 0x13b, subw 0x0, time 770816, (729,598), root:(734,623),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0xa00001,
    root 0x13b, subw 0x0, time 770816, (729,598), root:(734,623),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0xa00001,
    root 0x13b, subw 0x0, time 770867, (729,598), root:(734,623),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0xa00001,
    root 0x13b, subw 0x0, time 770867, (729,598), root:(734,623),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0xa00001,
    root 0x13b, subw 0x0, time 770868, (729,598), root:(734,623),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Revision history for this message
In , Ciso (cisoprogressivo) wrote :

I noticed that this happens also for multimedia keys.

Revision history for this message
In , Christian Esken (esken-kde) wrote :

Well, if it is like this, I can't do anything. 2,3,4 events simply mean 2,3 or 4 key presses.

I will close bug report, as it has nothing to do with KMix - it affects any other application which use those keys.

Here is a proposal for your further investigations:

This is either a hardware issue, or a driver/OS issue. You can check the former using a completely different OS. If it is not a hardware issue, please open a bag report either at your Linux distributor, or to someone else who might be applicable (Xorg?!?).

Revision history for this message
In , Aldoo (aldo-public) wrote :

Another proposal: this laptop is also sold by Dell with a preinstalled Ubuntu. This would be interesting to know if their ubuntu also hat this issue, and if not (and I it would surprise me if it did!), to inquire what they had to patch for it to work.
Emanuele, is your OS the preinstalled one?

Revision history for this message
In , Ciso (cisoprogressivo) wrote :

No it's not a preinstalled one, but if I install Ubuntu instead of Kubuntu everything works fine.
So where do you think I have to open this bug?

Revision history for this message
In , Christian Esken (esken-kde) wrote :

Not 100% sure, but as Kubuntu sounds like a good idea.

Revision history for this message
Ciso (cisoprogressivo) wrote :

The output of xev if I pressed the volumdown key is:
KeyRelease event, serial 31, synthetic NO, window 0x5800001,
    root 0x13b, subw 0x0, time 3913655, (789,217), root:(794,242),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

FocusOut event, serial 31, synthetic NO, window 0x5800001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 31, synthetic NO, window 0x5800001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 31, synthetic NO, window 0x0,
    keys: 68 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4
           0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

KeyRelease event, serial 34, synthetic NO, window 0x5800001,
    root 0x13b, subw 0x0, time 3913688, (789,217), root:(794,242),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

FocusOut event, serial 34, synthetic NO, window 0x5800001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 34, synthetic NO, window 0x5800001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 34, synthetic NO, window 0x0,
    keys: 59 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4
           0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

KeyRelease event, serial 34, synthetic NO, window 0x5800001,
    root 0x13b, subw 0x0, time 3913711, (789,217), root:(794,242),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

There is also a bug on Bug.KDE: http://bugs.kde.org/show_bug.cgi?id=178501

Revision history for this message
Ciso (cisoprogressivo) wrote :

Same problem on Kubuntu Jaunty

Revision history for this message
Ciso (cisoprogressivo) wrote :

The problem is still here with the last 2.6.28-8-generic kernel.

Revision history for this message
Rich Johnson (nixternal) wrote :

Confirming due to upstream report and assigning the kdemultimedia package as it seems to be a KMix issue at this time. Also we confirmed this issue here at the chicago bug jam.

Revision history for this message
In , Rjohnson-m (rjohnson-m) wrote :

We just verified this here today at the Ubuntu Global Bug Jam. Xev is reporting the key press correctly and KMix is reporting it as a double/triple tap. Talked about it on IRC with a few people and it seems they can also confirm it is KMix. Could you please review this and provide any more information that makes you think that it isn't KMix?

Revision history for this message
In , Ciso (cisoprogressivo) wrote :

I tried to do the test above (with xev) but this time with Kmix opened, and the output is doubled!
So I was wrong, and I think too that Kmix has something to do with this.

Changed in kdemultimedia:
status: Unknown → New
Revision history for this message
Ciso (cisoprogressivo) wrote :

The problem is still here in the Ubuntu Jaunty Final Release

Revision history for this message
Augusto (augu) wrote :

I confirm this bug on Kubuntu Jaunty 9.04 (freshly upgraded from Intrepid) on a Dell XPS M1330.
All multimedia keys worked fine for me in KDE 3.5 and I see this wrong behavior since KDE 4.1 (the first version I tried on Kubuntu 8.10).

I have attached in the related bug on KDE bugtracker (http://bugs.kde.org/show_bug.cgi?id=178501) three different tests I just perfomed using xev and hitting two different buttons (Mute and VolumeDown) _just one time_.

The first test is done outside KDE (I opened a second X server and launched xev from a xterm there, see attachment comments in the KDE bugtracker). You can see that only two key presses/releases are correctly detected.

The second test is done in a KDE 4.2 session, after closing KMix. You can see that multiple key presses/releases are wrongly detected.

The third test is done in a KDE 4.2 session, with KMix running. You can see that only multiple releases are detected (here also some focus changes are visible). KMix seems to "steal" key presses, but not key releases.

My conclusions from these tests are the following:
- It is not an hardware problem.
- It is not a kernel/driver problem.
- It is not a Xorg bug (at least not Xorg taken alone).
- It is related to KDE (outside a KDE session keys presses/releases are detected correctly).
- It is not a KMix bug, multiple key presses/releases are detected also after closing KMix, but I don't know if it's normal that KMix is stealing key presses, but not key releases from xev output.

So the question remains: what is the best place to report this bug?

I conclude saying that sometimes, but rarely, something "magic" happens (maybe when I play with xev) and suddendly all buttons begin to work correctly inside KDE and with KMix running. Today it happened just one time, but after a reboot the multiple key presses/releases came back. :(
I don't know what triggered the correct behavior; if I will discover it, I will write here a follow up.

Thank you for your attention!
Augu

Revision history for this message
In , Augusto (augu) wrote :

Created attachment 33069
xev output _outside_ KDE session

How to reproduce this output (on Kubuntu Jaunty 9.04 Final Release, upgraded from Intrepid):

(type CTRL-ALT-F1)

$ sudo Xorg :1 &
$ DISPLAY=:1 xterm

(type CTRL-ALT-F9)
(mouse over xterm)

$ xev

(hit Mute key only once)
(hit VolumeDown key only once)

Revision history for this message
In , Augusto (augu) wrote :

Created attachment 33070
xev output in a KDE session without KMix

(right click on Kmix systray icon > Quit)
(open a konsole window)

$ xev

(hit Mute key only once)
(hit VolumeDown key only once)

Revision history for this message
In , Augusto (augu) wrote :

Created attachment 33071
xev output in a KDE session with KMix

How to reproduce this output (on Kubuntu Jaunty 9.04 Final Release, upgraded from Intrepid):

(open a konsole window)

$ xev

(hit Mute key only once)
(hit VolumeDown key only once)

Revision history for this message
In , Augusto (augu) wrote :

I confirm this bug on Kubuntu Jaunty 9.04 (freshly upgraded from Intrepid) on a Dell XPS M1330.
All multimedia keys worked fine for me in KDE 3.5 and I see this wrong behavior since KDE 4.1 (the first version I tried on Kubuntu 8.10).

I have attached three different tests I just perfomed using xev and hitting two different buttons (Mute and VolumeDown) _just one time_.

The first test is done outside KDE (I opened a second X server and launched xev from a xterm there, see attachment comments).
You can see that only two key presses/releases are correctly detected.

The second test is done in a KDE 4.2 session, after closing KMix. You can see that multiple key presses/releases are wrongly detected.

The third test is done in a KDE 4.2 session, with KMix running. You can see that only multiple releases are detected (here also some focus changes are visible). KMix seems to "steal" key presses, but not key releases.

My conclusions from these tests are the following:
- It is not an hardware problem.
- It is not a kernel/driver problem.
- It is not a Xorg bug (at least not Xorg taken alone).
- It is related to KDE (outside a KDE session keys presses/releases are detected correctly).
- It is not a KMix bug, multiple key presses/releases are detected also after closing KMix, but I don't know if it's normal that KMix is stealing key presses, but not key releases from xev output.

So the question remains: what is the best place to report this bug?

I conclude saying that sometimes, but rarely, something "magic" happens when I play with xev and suddendly all buttons begin to work correctly inside KDE and with KMix running. Today it happened just one time, but after a reboot the multiple key presses/releases came back. :(
I don't know what triggered the correct behavior; if I will discover it, I will write here a follow up.

I copy this comment also on the Ubuntu bug tracker.

Thank you for your attention!
Augu

Revision history for this message
Augusto (augu) wrote :

I added a new comment on kde bugtracker, I copy it also here.

--

I have new info. I'm using synergy at work to control both my workstation and
my XPS1330 from a single keyboard and mouse. synsergy server is launched on the
workstation, and synergy client is running on the XPS1330.

I noticed that in this situation (synergys and synergyc running), if I move the
mouse on the XPS1330 screen (to control the XPS1330 via synergy) the laptop
multimedia keys work correctly inside KDE session and with KMix running.
Just one keypress at a time is detected.

If I move the mouse outside XPS1330 screen (I move back the mouse on the
workstation), the multimedia keys return to the bad behavior, and multiple key
presses are detected upon a single real key press.

So new info here:

- It's something related to Xorg (synergy uses Xorg to control multiple PCs
over the network with a single keyboard and mouse)
- It's related to KDE, because outside KDE (see my previous comments) the
multimedia keys work correctly.

I see no activity on this bug, maybe because the issue is not related directly
to Kmix. Can you please point me to the right place to report this issue?

XPS1330 is very well supported on Linux, and this issue on multimedia keys is
very annoying to me.

Thank you very much!

Revision history for this message
In , Augusto (augu) wrote :

I have new info. I'm using synergy at work to control both my workstation and my XPS1330 from a single keyboard and mouse. synsergy server is launched on the workstation, and synergy client is running on the XPS1330.

I noticed that in this situation (synergys and synergyc running), if I move the mouse on the XPS1330 screen (to control the XPS1330 via synergy) the laptop multimedia keys work correctly inside KDE session and with KMix running.
Just one keypress at a time is detected.

If I move the mouse outside XPS1330 screen (I move back the mouse on the workstation), the multimedia keys return to the bad behavior, and multiple key presses are detected upon a single real key press.

So new info here:

- It's something related to Xorg (synergy uses Xorg to control multiple PCs over the network with a single keyboard and mouse)
- It's related to KDE, because outside KDE (see my previous comments) the multimedia keys work correctly.

I see no activity on this bug, maybe because the issue is not related directly to Kmix. Can you please point me to the right place to report this issue?

XPS1330 is very well supported on Linux, and this issue on multimedia keys is very annoying to me.

Thank you very much!

Revision history for this message
zimt (teresa-gattringer) wrote :

I've been having the same problem for some time, it's also persistent with the latest KDE 4 version (KDE 4.2.90 (KDE 4.3 Beta2)) from Kubuntu Backports. All multimedia keys are affected, just as you described it used to work in KDE 3.5.10 (8.04).

Changed in kdemultimedia:
status: New → Invalid
Revision history for this message
In , Christian Esken (esken-kde) wrote :

Augusto,

thanks for your lengthy investigations. Looks really like a X11 issue.

So X.org would be a good place to report this, please see http://www.x.org/wiki/ , it states: "Use the xorg product in the freedesktop bugzilla to report bugs against X."

Closing bug

Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Upstream says it's an Xorg issue.

Changed in kdemultimedia (Ubuntu):
assignee: Richard Johnson (nixternal) → nobody
status: Confirmed → Invalid
Revision history for this message
Augusto (augu) wrote :

I recently SOLVED this issue, sorry if I didn't wrote an update here.

The trick (I'm not completely sure) was going to KDE System Settings >
"Keyboard and mouse", and playing a bit with "Enable keyboard repeat" in the
Keyboard page.

Maybe I just activated then deactivated it, then my problems with multimedia
keys are gone.
As I told you, I'm not completely sure on what resolved the multiple key
presses issue, but I was playing with settings in that page and suddenly the
issue is gone (also after rebooting the system).

Revision history for this message
In , Augusto (augu) wrote :

I recently SOLVED this issue, sorry if I didn't wrote an update here.

The trick (I'm not completely sure) was going to KDE System Settings > "Keyboard and mouse", and playing a bit with "Enable keyboard repeat" in the Keyboard page.

Maybe I just activated then deactivated it, then my problems with multimedia keys are gone.
As I told you, I'm not completely sure on what resolved the multiple key presses issue, but I was playing with settings in that page and suddendly the issue is gone (also after rebooting the system).

IMHO this strange issue is not (only) in Xorg as you suggested, because playing with a KDE configuration solved it.

Bryce Harrington (bryce)
affects: xorg (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)
Revision history for this message
Bryce Harrington (bryce) wrote :

Thanks for letting us know the issue is resolved.

Changed in xserver-xorg-input-evdev (Ubuntu):
status: New → Fix Released
Revision history for this message
Ryan Thompson (rct86) wrote :

This isn't fixed. The problem is that the silly touch-sensitive media keys on the m1330 act as though they were pressed for nearly 0.7 seconds, regardless of how long you actually touch them. You can work around the problem by setting your typematic rate initial delay to 700 milliseconds or more. This is the solution described above. However, this is just a workaround, and it's annoyting, because 700 ms is too long a delay for me. I know this problem is solvable, because the keys work correctly in GNOME. I think GNOME does things through dbus instead of watching directly for key press events.

Revision history for this message
In , Rct+bugs (rct+bugs) wrote :

This is not fixed, and it may be fixable in KDE.

The underlying issue is that the key-press events generated by the Dell XPS M1330's touch-sensitive media keys always last slightly less than 700 milliseconds, even if you touch the buttons for less time than that. If your typematic rate is set with an initial delay of less than 700 ms, you will generate multiple key presses, just as if you were holding down the button. As such, a work-around is to increase your typematic rate initial delay to 700 ms or greater. However, slowing your typematic rate may also drive you insane, so a real fix would be nice.

These buttons work correctly in GNOME, and I they do it by letting the keys generate DBus events and then catching the DBus events, or something. In any case, if KDE did it the same way, it might improve interoperability and fix this bug at the same time.

Revision history for this message
In , Rct+bugs (rct+bugs) wrote :

This is not an X11 bug. It is a hardware flaw in the Dell M1330's touch-sensitive multimedia buttons. Regardless of how long you press the buttons, they always generate a keypress event with a duration of about 680 milliseconds. This is long enough to trigger the typematic repeat with the default settings. You can work around this problem by setting the typematic delay to 700 milliseconds or longer, but that is a workaround, not a solution.

I know that GNOME handles these keys correctly, so it would probably be worthwhile to ask the person in charge of GNOME's media key support how they do things.

Revision history for this message
Dmitry Kazakov (dimula73) wrote :

I can confirm that this bug is still NOT fixed in KDE. I have M1330 too and face this bug even when an external USB keyboard is attached. And again, it can be temporarily (magically) cured by switching off and then on Keyboard repeat in KDE Configure Desktop dialog.

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Fix Released → New
Revision history for this message
In , Dmitry Kazakov (dimula73) wrote :

Well, i have new information about this bug. I doubt this problem is in hardware. I have the same laptop, but connected to an *external* keyboard. And external multimedia keys have the same bug! The keyboard is Microsoft Comfort Curve.

And the most strangest thing is that just deactivating/activating "keyboard repeat" in KDE configuration dialog fixes it. Delay is set to default and doesn't change during experiment - 660ms.

Revision history for this message
In , Rct+bugs (rct+bugs) wrote :

Apparently the KDE keyboard repeat settings are not applied when you first log in. So when you go into system settings and you deactivate and then reactivate the keyboard repeat settings, you are actually *changing* the delay, because the KDE settings are overriding the system default, which is a much shorter delay than 660 ms.

You can try this yourself. Open a terminal or text editor right after logging in, and hold down a key to test the autorepeat rate. Then go into system settings and twiddle the check box for autorepeat. Then go back to your text editor and test the autorepeat again. It will be slower.

The point is that Dmitry's proposed fix is really just the same workaround in disguise: slow down the autorepeat settings.

Anyway, I'd like to stress that this is a solvable problem, because GNOME solves it somehow. I wish I knew where to look in the GNOME source code for the solution, but I don't.

Furthermore, I'm not convinced that media keys should work in the same way as regular keys. For example, having any autorepeat on the mute button is ridiculous. There's no case where you would want a toggle button to autorepeat. It would be like having autorepeat on Caps Lock.

Changed in kdemultimedia:
status: Invalid → New
Bryce Harrington (bryce)
tags: added: kubuntu
Revision history for this message
In , Christian Esken (esken-kde) wrote :

Moving bug to "kdelibs".

Changed in kdemultimedia:
importance: Unknown → Medium
Revision history for this message
In , Adam Porter (alphapapa) wrote :

Is the M1330 the only laptop that suffers from this problem? Surely not.

It seems to me like all we need is a way to disable autorepeat on the media keys...or for the software to ignore repeat keystrokes on those keys. It's really frustrating when the play/pause button pauses and unpauses with a single touch...same for mute, skip back/forward, volume up/down, etc. Makes them nearly useless. :(

Revision history for this message
In , Rct+bugs (rct+bugs) wrote :

Actually, the problem seems to be gone on 4.6 on my laptop. But I also upgraded from Lucid to Maverick around the same time, which includes a kernel major version upgrade, so I'm not sure what fixed it.

Revision history for this message
In , Adam Porter (alphapapa) wrote :

I'm running 4.6 on Maverick but the problem is still as bad as ever.

Revision history for this message
penalvch (penalvch) wrote :

Ciso, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-input-evdev REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

no longer affects: kdemultimedia (Ubuntu)
Changed in xserver-xorg-input-evdev (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
In , elfio (helfio) wrote :

This bug is still there in my M1330 running Plasma 5.3-1 on Archlinux (everthing updated).

Revision history for this message
In , elfio (helfio) wrote :

Created attachment 94133
xev output of two taps on raise and low volume.

Revision history for this message
In , elfio (helfio) wrote :

Created attachment 94135
Workaround for this bug. Disable autorepat in certain keys.

Please attention!!

You have to check the script to set your keycodes before executing it. It disables autorepeat on multimediakeys (and bright keys which also had this problem in my laptop). My keycodes are in the script but yours could be different.

I hope this help.

Revision history for this message
In , Justin Zobel (justin-zobel) wrote :

Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!

Changed in kdemultimedia:
status: New → Incomplete
Revision history for this message
In , Bug-janitor (bug-janitor) wrote :

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Revision history for this message
In , Bug-janitor (bug-janitor) wrote :

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

Changed in kdemultimedia:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.