Bug 162856

For me (Debian with KDE 4.1 beta and Intel graphics), this bug is even worse than originally described. Yes, xrandr -o left causes the geometry to be off, but the system also becomes largely unresponsive to input. I can move the mouse / stylus but cannot click anything. Also, I cannot type anything further in Konsole to revert to xrandr -o normal . Thus, I have to restart the X server. I think this is not a bug with xorg because rotation of the screen still works fine in Xfce.

Also, the panel stays in the middle of the screen

Yesterday, I tried screen rotation with a friend's laptop who also has the current packages from Debian experimental. For that computer, the geometry was off, but there were no problems with the system becoming unresponsive in any way (see comment #1). So, I could revert the orientation with xrandr -o normal . Unfortunately, it looks as if the behavior I described in comment #1 may be an interaction between plasma and the hardware or the screen resolution or something.

Created attachment 26165 [details]
screenshot of desktop with taskbar in the wrong place

After upgrading to the xorg RC, the behavior is better. The system is no longer
unresponsive, and if you do xrandr -o left and then do something to cause a
repaint (like Alt-F2), then you get all of the real estate. Unfortunately, the
taskbar is about 1/3 of the way up the screen instead of at the bottom.

Created attachment 26166 [details]
screenshot of desktop with taskbar in the right place but too long

However, about one out of fifty times, the correct behavior almost happens, as
indicated by the screenshot where the sizes are (almost) correct and the
taskbar is at the bottom of the screen. However, the length of the taskbar is a
little too long and you cannot see some of the icons toward the right side or
the clock.

Created attachment 26246 [details]
screenied of rotated kde.. with confused plasma and krunner

I am having similar issues. 

See the screen shot for how the screen looks when rotated. Note how krunner is
off centered, when you push alt+tab the switcher pops up off center too.

If I restart plasma the desktop is expanded and the panel appears in the
correct place, however I have to restart kwin before krunner and the alt+tab
switcher appear in the correct place.

Another thing I've noticed. After switching from left/right back to the normal orientation windows cannot be maximized  correctly.

when I click maximize the window expands to fill the left/right resolution (900x1440) instead of the normal resolution (1440x900).

I can confirm weird things happening when using xrandr **w/desktop effects enabled**  on a week-old trunk build
I am using a resolution of 1280x800, when calling
"xrandr -o left" or "xrandr -o right"
apparently only the top (rel to orientation) 800x800pixels are avaiable, the other 800x480 zone apparently gets repainted only once as it shows a STATIC image of the wallpaper (sometimes even the kdm wallpaper!) or whatever it is supposed to be there. Windows are not drawn or painted in this area. I guess this is why the panel often is half-painted or not painted at all. However I can blindly interact with panel (i.e. switching application with the task manager) and windows (scrolling, clicking, moving)
Disabling desktop effects resolves the painting issue  (of course not the maximize issues or the "confused krunner" issue). 
Moreover the desktop switcher widget is confused too and displays the "vertical" desktops even when coming back to normal orientation. (should I file another  bug for this?

With 4.1.x the situation with xrandr -o had gotten pretty good for me. It took a few seconds and there was some screen glitches but it eventually got turned sideways and everything went to the proper locations.

With 4.2 beta2 Debian binaries / Intel graphics / recent Xorg, xrandr -o left now causes X to restart on me.

I can confirm this on KDE 4.2 Beta 2. 
When rotating the screen with desktop effects enabled (opengl) the X Server crashes and restarts (which of course might also be a problem of the intel drivers).
But with desktop effects disabled everything "works fine" except that plasma keeps its size at 1024x768, which then is half outside of the rotated resolution 768x1024. When resizing the screen with xrandr plasma also does not seem to react on the new screen sizes...

"the X Server crashes and restarts (which of course might also be a problem of the intel drivers). "

that would absolutely be a problem with the driver. the X server should never crash no matter what an app may do.

"plasma keeps its size at 1024x768"

which would likely mean it's simply not getting any updated information on the screen change. this will require someone with a machine where rotation works to go into the code and debug it. unfortunately rotation does not seem to work at all on my laptop.

For me, if I use KRandRTray to rotate the screen, the X server does not restart (but the geometry is still off). So, X restarting only happens when xrandr -o is called from the command line. 

Did some more testing:

> > "plasma keeps its size at 1024x768"
> which would likely mean it's simply not getting any updated information on the
> screen change. 

Yes and no:
When changing resolution with xrandr or krandrtray it also sometimes happens that plasma does not correctly resize so it probably isn't notified about that change, BUT: I can always correct that by killing plasma and restarting it. Then it fits perfectly into the new size.

BUT: when rotating the screen and then killing and restarting plasma, it still acts as if the screen was not rotated and uses 1024x768 instead of 768x1024 space.

While watching the dbus messages during screen rotation I noticed that when the screen is rotated the "size" of the screen is still communicated to be 1024x768, but the flag "rotation" is set to "90" instead of "0".
Maybe plasma is simply ignoring that flag? (didn't find the code that handles this yet)

this is all handled by kephal these days.

right ... one part of the problem seems to be the kephal bug: #168308 .
I attached a patch there that at least works for me (exchanges width<->height when rotated) such that kwin and plasma use the right dimensions (at least when i kill and restart plasma).

kephal correctly triggers a outputResized signal but it seems as if plasma doesn't notice. So that is the bug here then?

Actually when starting plasma i get:
Object::connect: No such signal OrgKdeKephalConfigurationsInterface::statusChanged()
might that be causing problems?

another update:
I always tested with auto-hide taskbar (and assumed that plasma did not get the right size, when the taskbar either was apprearing at a wrong position on the screen or was not visible because it was outside the screen).
But with the patched kephal, plasma does seem to get notified about the new screen sizes: when i disable auto-hide of the taskbar it is always in the right position.

So the problem is: when the taskbar is auto-hidden and the screen size changes, the mouse area that triggers the taskbar to come back up does not seem to be updated - at least i can not bring it up no matter where i move the mouse...

(In reply to comment #16)
> So the problem is: when the taskbar is auto-hidden and the screen size changes,
> the mouse area that triggers the taskbar to come back up does not seem to be
> updated - at least i can not bring it up no matter where i move the mouse...
> 

I actually just fixed that yesterday, or so I hope. ;) Can you make sure kdebase/workspace/plasma/shells/desktop is completely up to date and test again? thanks...

PanelView::pinchContainmentToCurrentScreen() should be called on screen geometry changes and that now calls recreateUnhideTrigger() which should, in theory, fix this issue.

indeed trunk works perfectly (together with my patched kephal version of bug #168308).
Thanks Aaron, always a pleasure to see bugs fixed before they are actually reported ;) Nice work!

Hope kephal gets correct rotation support for the release of kde 4.2. Then it will finally be useable on tablet pcs :)

Thanks stefnn and aseigo for tracking this bug down!!!

But is it anticipated that svn 906592 would have all the necessary patches in? I am still seeing the previous behavior using binaries built from that svn snapshot.

kephal as it is in svn currently does not include the full patch.
See my last comment (#10) of bug #168308 for a patch that does the missing things. (with that kwin and plasma get the screensizes right).

But i have to admit, that on my system after updating from gentoo kde ebuilds 
4.1.85 -> 4.1.87 (not sure what exact svn version that is, but its from 20090101 i think) and using plasma-workspace svn version 905516, plasma does not always handle the rotation right. (Depending on what panels i have and if they auto-hide or not - in some combinations they are positioned right when rotating, in some others i have to restart plasma (killall plasma && plasma) to get all of them back. But this might be due to the mixing of different versions of libplasma and plasma-workspace. For now i found a configuration that works for me and if necessary i restart plasma after rotation.

But as i said above: plasma will only get the right dimensions with the patched kephal - without it, it has no chance to do things right.