I was able to get screen rotation working by doing "xhost :local". (This wouldn't be secure if I had other users on my system, but I'm not sure how else to correct the permissions issues)
(I put it in my startup applications so it would persist across sessions)
I also adjusted the rotation behavior:
This will make it switch through normal->rotated 90->rotated 180->normal instead of just normal->rotated 90->normal.Code:case "$ROTATION" in right) NEW_ROTATION="inverted" ;; normal) NEW_ROTATION="right" ;; *) NEW_ROTATION="normal" ;; esac
Foone, can you elaborate on how you got this working, and the difference between this method and the method proposed by the original post?
My method was in addition to the method listed in the first post, as it didn't work for me. After some debugging, I found that making the change I listed (xhost local made it work.
The other change is just a behaviour change I made which I thought others might find useful.
If you've followed the first post's guide on rotation and you still can't rotate, try typing "xhost local:" in a terminal and pushing the rotate button, see if that fixes it like it did for me.
It's not the missing /var/lib/acpi-support/screen-rotation as it isn't supposed to exist first run. It's a file that keeps the last rotation setting and is created after a successful rotate so next time the rotate runs it will rotate to a different orientation. If it doesn't exist it will just use the default 'right' rotation and then create the file.
The actual problem (at least for me) is a bug in the getXConsole function (It's pulled in from: /usr/share/acpi-support/power-funcs), there is some awk error thrown.
I suspect that the true problem lies with the fgconsole command that getXConsole calls. It always results in "Couldn't get a file descriptor referring to the console". Although the error I was getting was in awk (which is in getXUser called from getXConsole).
I believe the simplest solution would be to remove getXConsole and manually set the DISPLAY=":0" and XAUTHORITY="/home/yourusername/.Xauthority". That would break it if you have other userlogins or if you have more than 1 Xorg running at once though.
So... I've gotten the screen to rotate. You are right, that file just wasn't there the first time so I created it manually but now the script updates it and works fine. HOWEVER...
My button still doesn't work. Basically, I know something (kernel?) is capturing or recognizing the key press, because in dmesg and the system log I get this error message:
eeepc_wmi: Unknown key e4 pressed
eeepc_wmi: Unknown key e5 pressed
I assume this is the press and release of that silver little rotate button. It seems that X does not capture or realize that a button was pushed at all...
I'm an linux noob if you haven't guessed it already haha but I'm trying. I'm not sure I want to try removing getXConsole just yet because its not the same error... but, someone should know better than me lol, any ideas?
Last edited by rentabuddha; October 19th, 2010 at 04:28 AM.
I get some "can't open display :0" and "No protocol specified" errors (even when I try to specify a xrandr protocol.
One problem might be that "XAUTHORITY=/var/run/gdm/auth-for-hegemon-hU9EIr/database" according to `env`, not /home/hegemon/.Xauthority Having a random directory means no hard coding hacks since it will just be different next login.
When I have time later I'll dump debug statements into everything and see where exactly getXConsole is failing.
In anycase the xhost command in a login script as mention above sounds like a good idea provided your not too worried about local security.
Last edited by H3g3m0n; October 19th, 2010 at 05:32 AM.
Can you play divx videos on 10.10 without any problems?
Last edited by rentabuddha; October 20th, 2010 at 11:22 PM.