ALT+PrtSc not recognised: breaks built-in screenshot function

Looks related to bug 198748 as in a terminal if I do ALT+PrtSc+H I get the magic SysRq key help, so it looks like the kernel is trapping ALT+PrtSc.

If I disable the sysrq behaviour in the kernel with:-

sysctl -w kernel.sysrq=0

I can then subsequently use ALT+PrtSc (although in GNOME it shows as ALT+SysRq rather than ALT+Print Screen as expected).

Seems to be a kernel bug rather than X as first envisaged.

reproduced here, works find in Lucid, no response to alt+prtscr in Maverick. Prtscr on it's own works as expected.

Added regression-potential and assigned ubuntu-release-notes as per https://wiki.ubuntu.com/QATeam/RegressionTracking

From a kernel perspective, this appears to be expected behavior. By default, SysRq handling is enabled in the kernel. Thus by pressing Alt+PrintScreen it is correctly being interpreted as the SysRq key. As Alan Pope noted, if he disables SysRq handling in the kernel, Alt+PrintScreen can then be used to capture a screenshot of the currently selected window. There seems to be a few solutions one could propose:

1) Disable SysRq handling by default. This is a simple 1 line change by adding "kernel.sysrq = 0" to /etc/sysctl.conf . Those then wanting to enable SysRq handling can do so by either "echo 1 > /proc/sys/kernel/sysrq" or "sysctl -w kernel.sysrq=1"
2) Reassign the keyboard shortcut to capture a screenshot of the currently active window to something other than Alt+PrintScreen, eg. use Ctrl+PrintScreen or something.
3) Regress expected kernel behavior to not interpret Alt+PrintScreen as SysRq when SysRq handling is enabled. I personally don't feel this is the correct solution.

I think option 1 seems to be the most reasonable solution.

This is not a kernel bug at all. Alt+PrintScreen has a pre-existing meaning, which is "SysRq", as printed on the keycaps of nearly all PC keyboards. SysRq is not an appropriate keybinding for taking screenshots of a window. This is a bug in the keymaps, not in the kernel.

> 1) Disable SysRq handling by default. This is a simple 1 line change by
> adding "kernel.sysrq = 0" to /etc/sysctl.conf . Those then wanting to
> enable SysRq handling can do so by either "echo 1 >
> /proc/sys/kernel/sysrq" or "sysctl -w kernel.sysrq=1"

This has the result that the screenshotting behavior on the desktop varies according to whether Magic SysRq is enabled or not in the kernel. That's not appropriate either. GNOME needs to just pick a default keybinding that hasn't already been spoken for by the kernel for the past 15 years.

Reassigning this to gnome-settings-daemon, which is responsible for this shortcut.

(Also, bear in mind that when Ctrl+Alt+Backspace was disabled by default in X, part of the rationale was that you could more effectively kill off a broken X server using SysRq; so dropping SysRq would have concrete practical impacts on troubleshooting of stock Ubuntu systems.)

If we disabled SysRq, will we still be able to Alt+SysRq+K ?
If not, option 2 seems better..

How was Alt+PrtSc possible earlier? What seems to have changed now?

Gah! i wish lp implemented mid-air clash from bugzilla! I seem to have opened the page before slangasek commented! :/

The handling for this key is done by the window manager

Whilst I agree that it's undesirable to have two parts of the system fight for the same keypress, it seems this is well known. From wikipedia:-

http://en.wikipedia.org/wiki/Magic_SysRq_key

"Under graphical environments (such as Gnome or KDE) 'Alt'+'PrintScrn/SysRq'+key combination generally only leads to a screenshot to be dumped. To avoid this Print Screen feature the magic SysRq combination should be additionally prefixed by Ctrl, becoming 'Ctrl'+'Alt'+'SysRq'+key. "

this is clearly a regression. we use alt+printscreen for ages ... in lucid it worked.

Did anyone find out what was changed this cycle to cause this regression?

marking RC as noone could tell me in -desktop and -devel that this was an explicitly decided change somewhere.

IMO, if we cannot find out why this happened, we should let sysrq regress in kernel default settings until we find the right fix, rather than a long standing default UI binding.

one idea is that something with the keymap changed that causes this as the print key now shows up as "sysrq" rather than print according to popeys comment 13

Is this metacity specific? I'm on compiz, using an en_US keyboard layout, and the printscreen key has behaved the same as it used to do in the last 15 years or so: PrintScr does a screenshot, and Alt+PrintScr is SysRq, just as printed on the key.

@Martin, tried under Lucid? ALT+PrScr used to snapshot a window.

Alan Pope [2010-10-04 9:19 -0000]:
> @Martin, tried under Lucid? ALT+PrScr used to snapshot a window.

Yes, I am both using SysRq and PrintScr regularly, and I didn't notice
a problem in lucid either. Maybe it's really specific to en-GB, I'm
not using that (only en-US and de-nodeadkeys).

If Alt+PrintScreen triggers a screenshot, that's indeed a bug.

I'm using an de_DE keyboard and till 10.04 Alt+PrtSc, a screenshot of the active windows was taken, as specified in the keyboard settings and as default behavior for many Linux Distributions and even Windows. The SysRq is only useful, if you press an additional key. And SysRq was working too in Ubuntu <10.10.

It's always been the case, on both GNOME and Windows that ALT+PrtScrn takes a screenshot of the active Window. This is a really bad regression from a user experience POV, especially for non-technical users that take screenshots of active windows to send when they have issues.

If we are now saying that ALT+PrntScrn *shouldn't* take a screenshot of the active window then we should at least have an alternative key binding sorted out and have it really well documented by release, otherwise revert whatever change caused this until Natty.

I've been training users for about five years that alt-printscreen takes that picture they need to attach for there bug report. Alt-PrintScreen has previously worked for the current window + more recently, since bug #74008 was resolved.

It's also worth noting that according to http://en.wikipedia.org/wiki/Print_screen it's also the behaviour in KDE. Is Kubuntu showing the same problem?

We just asked a KDE user on irc to test and ALT+PrScr does _not_ take a screenshot for him (running Lucid with backported KDE packages). Indeed in the keyboard configuration screen on Kubuntu it refused to accept ALT+PrScr as a valid keypress.

"The key you just pressed is not supported by Qt"

If alt+prscr is really rendering a sysrq event, it would appear that sysrq is not a bindable event. I can't get it to show up in anything (including xev).

While I can see the technical argument for making alt trigger the alternate key, the solution in the latest kernel is at least 10 years too late. There is too much documentation and too much "known behaviour" to try (or want) to reverse things now without upsetting everybody who expects a windowshot from an alt+prscr combo.

It's also well known that if you want sysrq, you use control+alt+prscr. I assume this key-combo is also broken now (or it renders as control+sysrq).

Everything about this stinks to me and I think we should fight upstream all the way on this, disabling the new kernel configuration by default.

Oli [2010-10-04 11:42 -0000]:
> While I can see the technical argument for making alt trigger the
> alternate key, the solution in the latest kernel is at least 10 years
> too late.

I don't believe that Maverick's kernel changed anything in that
regard; the SysRq key functionaly has been pretty much the same since
Linux' inception. It's more likely that something changed in X.org or
the desktop environments.

> It's also well known that if you want sysrq, you use control+alt+prscr.

Where is that documented? It's at least news to me.

> I assume this key-combo is also broken now (or it renders as
> control+sysrq).

At least here it works just like alt+sysrq, i. e. actually triggers a
sysrq.

> Everything about this stinks to me and I think we should fight upstream
> all the way on this, disabling the new kernel configuration by default.

Do you have proof (or a patch) which would actually identify this as a
kernel change? That would be helpful to actually understand what's
going on here. Thanks in advance!

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

This may be relevant:

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commitdiff;h=97f5f0cd8cd0a05449cbb77d1e6f02e026875802

I'm using a USA keyboard layout and Alt+PrScr does indeed take a screenshot for me in Lucid.

With USA layout, I was able to do Alt+PrtSc in Lucid, and also Alt+SysRq+K
But same USA layout, in Maverick I can *not* do a Alt+PrtSc , but can Alt+SysRq+K.
If i change the shortcut from Keyboard Shortcuts, i can not even again set it to Alt+Print , but i can set to every other combo.

Martin Pitt:

> Do you have proof (or a patch) which would actually identify this as a kernel change?

The only proof I had was anecdotal: I started using 2.6.35 on Lucid long before upgrading to Maverick. Alt-PrintScreen was broken back then, before any of Maverick's X changes were near my system.

But if the patch by Dmitry Torokhov is the cause of this behavioural change (which it does look like it could be - it's making sysrq bypass evdev), we need to nail down the rationale (if it was intended) or blindly counter the patch... I can't see there being enough time to send this upstream, get a fix and get it back through trunk into maverick before release.

On Mon, Oct 04, 2010 at 12:49:23PM -0000, Martin Pitt wrote:
> Oli [2010-10-04 11:42 -0000]:
> > While I can see the technical argument for making alt trigger the
> > alternate key, the solution in the latest kernel is at least 10 years
> > too late.

> I don't believe that Maverick's kernel changed anything in that
> regard; the SysRq key functionaly has been pretty much the same since
> Linux' inception. It's more likely that something changed in X.org or
> the desktop environments.

Right. I've been using Alt+PrtSc for SysRq for 15 years, and the one and
only time I experienced this key combination generating screenshots (at the
time of the Dallas UDS), it was a bug that resulted in much swearing from
everyone experiencing it.

> > It's also well known that if you want sysrq, you use
> control+alt+prscr.

> Where is that documented? It's at least news to me.

And to me.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

From my POV the patch should be reverted, cause you can bypass evdev after emitting Ctrl+Alt+SysRq+R. Also, Alt+SysRq under X is taking screenshots since I use Linux (~11years). I don't see any need for this patch. And I don't see, why Ubuntu should work another way than all other distros at SysRq. Also there seems to be a general problem with SysRq. 'cat /proc/sys/kernel/sysrq' returns 0 on my installation and that should deactivate SysRq's at all, but it don't. Could this be a sideeffect of the patch?

Oli [2010-10-04 16:32 -0000]:
> But if the patch by Dmitry Torokhov is the cause of this behavioural
> change (which it does look like it could be - it's making sysrq bypass
> evdev)

Yes, I agree, this seems to be it. I checked with /lib/udev/keymap -i,
and SysRq doesn't produce an evdev event, as intended by this patch.
Thanks for confirming!

> I can't see there being enough time to send this upstream, get a fix
> and get it back through trunk into maverick before release.

No, at this point it needs to become a stable release update either
way, I'm afraid.

The drawback for me at least (even if I don't really care that Alt+printscreen isn't taking any more window screenshot) is that the dedicated key combination (which is Fn + print screen here) doesn't work at all anymore. I had to use it some times in the development release, and I couldn't and didn't think that Alt+print screen was revert and activated again…

Now the release is out, any chance this can be looked at for a 10.10 SRU?

I'm only a user and from a user point of view I must say: "If it's not broken don't try to fix it". I believe I speak for many users who are used to do Alt+PrtScn to capture for ever. Even if this is right, don't try to re-educate the entire pc user population as this will result in general frustration and disappointment.

For the issue itself, I've used xev and found that on my pc the PrtScn button produces an Insert button press event. I changed the keybinding event from "<Alt>Print" into "<Alt>Insert" and now I can do screen-shots using the Alt+PrtScn buton combination again, but I would like to see that everything is back as it used to be.

I can confirm that alt+print doesn't work on my up to date ubuntu 10.10 amd64.

Workaround:
sudo sysctl -w kernel.sysrq=0

This needs to be fixed soon or many user will get annoyed!

Is this (sudo sysctl -w kernel.sysrq=0) a permanent thing or should I do it every time I boot?

@AmiG: You need to do it after every reboot or add it to /etc/sysctl.conf.

I'm currently using a Spanish keyboard layout, and up until Lucid I could both take a screenshot with Alt+PrtScn and use magic SysRq keys without additional modifier keys (so e.g. Alt+PrtScn+B rebooted the system). Now I'm experiencing this bug.

There is no reason to change the old behaviour. If Alt+PrtScn is pressed and then released, obviously no SysRq event was intended and a screenshot should be captured. On the other hand, if Alt+PrtScn+(another key) is pressed, then it should be interpreted as SysRq.

Also, this happens on Compiz too, so it's not Metacity-exclusive.

Just tried and reproduced this bug on my laptop too.
Problem is, on my laptop's keyboard, PrtScn and SysRq are on different physical keys. So the automatic interpretation of Alt+PrtScn as a SysRq event is not only counter-intuitive, it's plain wrong.

Fibonacci, what model laptop do you have?

@William: HP Nc6400.

The issue is more in kernel preempting the call than in any window manager.

It should be marked as invalid on Metacity too, then.

Added a kernel task to the bug.

@Fibonacci It has nothing to do with the window manager (metacity, compiz, whatever) because it's the kernel. It's blocking the sysrq key permeating to the rest of the system.

You can prove this very easily in xev.

@Oli Actually it's blocking Alt+PrtScn. As I stated before, SysRq is on a different physical key on my laptop, yet Alt+PrtScn is blocked.

Prt Screen works
Alt+Prt Screen doesnt for me.. :(
clean Ubutun 10.10 + latests updates.

Prt Screen works
ALT+F2 + "gnome-screenshot -w" works
Alt+Prt Screen doesnt for me.. (clean Ubutun 10.10)

Me too. Print Screen works, Alt+Print Screen/SysRq does not. Ubuntu 10.10.

Rather than setting SysRq to Ctrl-Alt-PrintScreen, as it's done with other keybindings such as Alt-Fx -> Ctrl-Alt-Fx, or completely disabling it, I'd just change the keybindings:
* PrintScreen: "Save Screenshot" dialog
* Shift+PrintScreen: "Save Screenshot" dialog for current window
Additionally, these "direclty copy to clipboard" shortcuts might be useful:
* Ctrl+PrintScreen: copy screen to clipboard (lossless quality)
* Shift+Ctrl+PrintScreen: copy window to clipboard

> I'd just change the keybindings

That would break well-known user experience. Users are used to press PrintScreen/Alt+PrintScreen on all platforms (even Windows).

If there's a choice between breaking SysRq and Alt+PrintScreen - we should consider breaking SysRq, because:
 * Making single window screenshots is much more demanded task that using SysRq
 * SysRq is used for debugging that itself is not ordinary use case comparing to making screenshots
 * SysRq "has no standard use" http://en.wikipedia.org/wiki/System_request

> Additionally, these "direclty copy to clipboard" shortcuts might be useful

Yes, separate keybindings for direct copying to clipboard would be very handy.

Why not grabbing Alt+PrtScn when it is pressed alone, but allowing it to pass through to the kernel as a SysRq event when it is pressed together with another key and ONLY IF SysRq is actually on the PrtScn key?

I just checked the latest Natty 11.04 daily: both Alt+PrtScn and Alt+PrtScn+REISUB work again as expected.

@Fibonacci: I don't have a separate SysReq key. If it still does nothing in Natty and you want to change that, I'd propose to open a new bug report, as this one is about the broken Alt+PrtScn in Maverick.

tonnzor is absolutely correct in post #53 ... personally I have used Alt+PrtScrn for a windowshot thousands of times on all releases of Windows and an older Ubuntu Linux as well as Linux Mint 8 and 9 (it is 'broken' on Mint 10). I have never used SysRq in my many years of computing and so I don't really care (personally) what happens to it. Alt+PrtScrn for a windowshot is indeed a "well known user experience". Please don't leave it broken.

@Oliver: Alt+SysRq works as expected on my laptop. It's just that Alt+PrtScn duplicates that function.

My understanding of Alt+PrtScr/SysRq was always like that:

LeftAlt+PrtScr/SysRq produces screenshot of active window

RightAlt+PrtScr/SysRq produces SysRq event

On some keyboards RightAlt is labeled as "Alt Gr".

In Ubuntu 10.10 LeftAlt+PrtScr/SysRq produces SysRq
and I think that's wrong.

I've always used RightAlt+PrtScr in Ubuntu and Windows to take a
snapshot of the active window.
I'm still using Lucid (partly because of this bug as I often take
snapshots for instructional purposes) and both LeftAlt+PrtScr and
RightAlt+PrtScr take snapshot the active window.

On 24 February 2011 19:31, Miroslav <email address hidden> wrote:
> My understanding of Alt+PrtScr/SysRq was always like that:
>
> LeftAlt+PrtScr/SysRq produces screenshot of active window
>
> RightAlt+PrtScr/SysRq produces SysRq event
>
> On some keyboards RightAlt is labeled as "Alt Gr".
>
> In Ubuntu 10.10 LeftAlt+PrtScr/SysRq produces SysRq
> and I think that's wrong.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/642792
>
> Title:
>  ALT+PrtSc not recognised: breaks built-in screenshot function
>
> Status in Release Notes for Ubuntu:
>  New
> Status in “compiz” package in Ubuntu:
>  Invalid
> Status in “linux” package in Ubuntu:
>  Confirmed
> Status in “metacity” package in Ubuntu:
>  Invalid
> Status in “compiz” source package in Maverick:
>  Invalid
> Status in “linux” source package in Maverick:
>  New
> Status in “metacity” source package in Maverick:
>  Invalid
>
> Bug description:
>  Binary package hint: xkeyboard-config
>
>  On an EN-GB keyboard (and maybe others) ALT+PrtSc is the default
>  keyboard shortcut for "Take a screenshot of a window" as configured in
>  System -> Preferences -> Keyboard Shortcuts. However the system
>  doesn't seem to respond to that keyboard combination at all. Pressing
>  ALT+PrtSc on a default Maverick install does nothing. Indeed
>  attempting to _set_ that keyboard shortcut in the Keyboard Shortcuts
>  dialog results in it not being registered.
>
>  Workaround:
>  sudo sysctl -w kernel.sysrq=0
>
>  Steps to reproduce:-
>
>  1) Try to screenshot the entire desktop with PrtSc - this works
>  2) Try to take a screenshot of one active window with ALT+PrtSc - nothing happens.
>
>  Additionally
>
>  1) Navigate to System -> Preferences -> Keyboard Shortcuts
>  2) Scroll down to Desktop -> Take a screenshot of a window, and then click that line in order to set a keyboard shortcut for the action
>  3) Press ALT+PrtSc - nothing happens
>  4) Press a different keyboard combination such as CTRL+PrtSc or Super/Windows+PrtSc - this works
>
>  Additionally
>
>  1) Open a terminal
>  2) Run 'xev' and then press ALT+PrtSc. Observe data in the xev terminal window when ALT is pressed, but nothing for ALT+PrtSc
>
>  Seems a fairly critical regression bug given we document this keyboard
>  shortcut in the help, and it's very commonly used by documenters and
>  people getting support. It works fine in previous releases.
>
>  ProblemType: Bug
>  DistroRelease: Ubuntu 10.10
>  Package: xkb-data 1.8-1ubuntu8
>  ProcVersionSignature: Ubuntu 2.6.35-22.32-generic 2.6.35.4
>  Uname: Linux 2.6.35-22-generic x86_64
>  NonfreeKernelModules: nvidia
>  .proc.driver.nvidia.version:
>   NVRM version: NVIDIA UNIX x86_64 Kernel Module  256.53  Fri Aug 27 20:27:48 PDT 2010
>   GCC version:  gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4)
>  Architecture: amd64
>  CurrentDmes...

>Graham Inggs

Do you have laptop or desktop?

On the laptop there is usually need for use of
Fn+PrtScrn/SysRq combination to get SysRq event.
In my case Fn+PrtScrn/SysRq does the same what
PrtScrn alone does (...) and I get SysRq event by using
LeftAlt+PrtScr/SysRq or RightAlt+PrtScr/SysRq,
what is clearly wrong.

I'd appreciate to get window-snapshot function back
for LeftAlt+PrtScr/SysRq or even RightAlt+PrtScr/SysRq
and SysRq event for Fn+PrtScrn/SysRq.

I have always used left Alt for both screenshots and SysRq events. There's never been a problem in my system because of that.

> Miroslav:
> Do you have laptop or desktop?

I'm using a desktop.

FN+PRTSC works perfect on toshiba satellite l500 laptop FN+ALT+PRTSC doesnt do anything

Still broken on Natty.

Not broken for me anymore. I'm in 11.04, fresh install.

It works for me again after installing 11.04. But I did a complet new install, not an upgrade, cause that messed up two of my systems. Maybe it's different when just doing an upgrade from >11.04.

Well, I can set Alt+PrtScn as a shortcut, but it's interpreted as Alt+SysRq. Don't know what impact would that have on Magic SysRq Keys.

I have just done an install of 10.10 64 bit then an upgrade to 11.04, alt+prtscr now works as expected and takes a screenshot of the current window.

Until now, I thought it was a kernel bug... But it works fine in Fedora
15.

Why is this Invalid, it doesn't make sense because it's reproducible.. and affects thousands of people..
Its still a issue with 10.10

This is not a new regression for Oneiric and is therefore not suitable for inclusion in the release notes. The prior release notes have shipped, and therefore marking task as Invalid.

Thanks.

Is this bug still propagating to new versions, or has it been fixed?

Regards,
Art in Carlisle PA USA

Dave Walker wrote:
> This is not a new regression for Oneiric and is therefore not suitable
> for inclusion in the release notes. The prior release notes have
> shipped, and therefore marking task as Invalid.
>
> Thanks.
>
> ** Changed in: ubuntu-release-notes
> Status: New => Invalid
>

Florian Sievers (#31) is right: in a clean Maverick install, 'cat /proc/sys/kernel/sysrq' (or 'sudo sysctl -a | grep kernel.sysrq') shows kernel.sysrq=0 , but in fact sysrq's are enabled (and eating up Alt+PrtScn). If i set it as 'sudo sysctl -w kernel.sysrq=0', supposedly it wouldn't change anything, since its already 0, but yet it disables sysrqs and allows me to take windowshots again. So currently this is really a mess.

If this is fixed for Natty, Oneric, great. But for Maverick it is not, so please at least issue an SRU to fix that! It is *very* annoying, and newcomers and novice users will find this *very* frustrating, to say the least.

In Lucid, both worlds were happy: Alt+PrnScr alone took windowshots, and Alt+PrnScr+<somekey> triggered Sysrqs. Maverick *should* have the same behaviour.

Also, as spoken here several times: this is expected even from Windows users. Sysrq's can also be triggered with Right Alt (AltGr here) + PrnScr. Taking windowshots is *far* more common then Sysrqs (meant for emergencies only).

Those who know what a sysrq is can easily workaround this. Most of "screenshoters" (=regular users) can not.

Please revert to the expected behavior!

On precise (fresh install):

Alt-PrtScn does a full-screen screenshot (screenshot is taken when I release Alt). My keyboard settings pane still says that Alt-Print should screenshot a single window.

I haven't run sysctl and my sysrq value seems to have defaulted to 1:

$ cat /proc/sys/kernel/sysrq
1

Except that something has modified it:

$ ls -ul /proc/sys/kernel/sysrq
-rw-r--r-- 1 root root 0 Aug 8 09:13 /proc/sys/kernel/sysrq
$ ls -l /proc/sys/kernel/sysrq
-rw-r--r-- 1 root root 0 Aug 8 09:13 /proc/sys/kernel/sysrq

(That's 3 minutes before I started writing this comment.) I haven't done any sudo commands today, but maybe one of the PrtScn key combos did it?

Maverick EOL -> Won't Fix.

Alan Pope, 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 linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]