Bug#598097: eeepc-acpi-scripts: vga toggling not working: `xrandr -q`: No protocol specified
Paul Menzel
Package: eeepc-acpi-scripts
Version: 1.1.10
Severity: normal
User: debian-ee...@lists.alioth.debian.org
Usertag: features
*** Please type your report below this line ***
Dear Debian folks,
I noticed that VGA toggling by using Fn + F5 is not working for me. I am using DebPkg:gdm3 to log into LXDE.
When the login of GDM 3 is shown Fn + F5 works. But when I am logged into LXDE it does not anymore. Somehow xrandr is failing.
$ sh -x /etc/acpi/actions/vga-toggle.sh
[…]
+ getvga_status
+ xrandr -q
No protocol specified
Can't open display :0
+ STATUSTEXT=
+ head -n1
+ grep ^VGA
+ echo
+ STATUSLINE=
+ cut -d -f 2,3
+ echo
+ STATUS=
+ cut -d -f 1
+ echo
+ VGA=
+ cut -d -f 1
+ head -n1
+ grep ^LVDS
+ echo
+ LVDS=
+ return 2
+ xrandr --output --off --output --auto
No protocol specified
Can't open display :0
Running `xrandr -q` from a LXTerminal works though.
Please tell me, if I need me to provide more information.
Thanks,
Paul
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages eeepc-acpi-scripts depends on:
ii acpi-support-base 0.137-5 scripts for handling base ACPI eve
ii acpid 1:2.0.6-1 Advanced Configuration and Power I
ii pm-utils 1.3.0-2 utilities and scripts for power ma
ii rfkill 0.4-1 tool for enabling and disabling wi
Versions of packages eeepc-acpi-scripts recommends:
ii alsa-utils 1.0.23-2 Utilities for configuring and usin
Versions of packages eeepc-acpi-scripts suggests:
pn aosd-cat <none> (no description available)
ii gnome-osd 0.12.2-1 OSD message framework for GNOME
ii ttf-bitstream-vera 1.10-8 The Bitstream Vera family of free
ii ttf-dejavu 2.31-1 Metapackage to pull in ttf-dejavu-
-- no debconf information
Paul Menzel
The affected packages were not changed lately, so I am still able to
reproduce this.
Does someone have an idea what could be wrong. I looked at the reports
of DebPkg:gdm3 [1] but could not find anything related.
Thanks,
Paul
[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=gdm3;dist=unstable
> -- System Information:
> Debian Release: squeeze/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
>
> Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages eeepc-acpi-scripts depends on:
> ii acpi-support-base 0.137-5 scripts for handling base ACPI eve
> ii acpid 1:2.0.6-1 Advanced Configuration and Power I
> ii pm-utils 1.3.0-2 utilities and scripts for power ma
> ii rfkill 0.4-1 tool for enabling and disabling wi
>
> Versions of packages eeepc-acpi-scripts recommends:
> ii alsa-utils 1.0.23-2 Utilities for configuring and usin
>
> Versions of packages eeepc-acpi-scripts suggests:
> pn aosd-cat <none> (no description available)
> ii gnome-osd 0.12.2-1 OSD message framework for GNOME
> ii ttf-bitstream-vera 1.10-8 The Bitstream Vera family of free
> ii ttf-dejavu 2.31-1 Metapackage to pull in ttf-dejavu-
>
> -- no debconf information
>
> _______________________________________________
> Debian-eeepc-devel mailing list
> Debian-ee...@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
Ben Armstrong
> The affected packages were not changed lately, so I am still able to
> reproduce this.
>
> Does someone have an idea what could be wrong. I looked at the reports
> of DebPkg:gdm3 [1] but could not find anything related.
Are you logged in as display :0.0 or not?
echo $DISPLAY
Ben
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Menzel
> On 12/11/10 07:05 AM, Paul Menzel wrote:
> > The affected packages were not changed lately, so I am still able to
> > reproduce this.
> >
> > Does someone have an idea what could be wrong. I looked at the reports
> > of DebPkg:gdm3 [1] but could not find anything related.
>
> Are you logged in as display :0.0 or not?
>
> echo $DISPLAY
It seems I am not.
$ echo $DISPLAY
:0
Thanks,
Paul
Ben Armstrong
:0 should be fine, too.
Please do the following and report the output:
su -
. /usr/share/eeepc-acpi-scripts/functions.sh
set -x
detect_x_display
Thanks,
Paul Menzel
> On 12/11/10 08:12 AM, Paul Menzel wrote:
> > Am Freitag, den 12.11.2010, 07:31 -0400 schrieb Ben Armstrong:
> >> Are you logged in as display :0.0 or not?
> >>
> >> echo $DISPLAY
> >
> > It seems I am not.
> >
> > $ echo $DISPLAY
> > :0
>
> :0 should be fine, too.
>
> Please do the following and report the output:
>
> su -
> . /usr/share/eeepc-acpi-scripts/functions.sh
> set -x
> detect_x_display
$ sudo su -
machine:~# . /usr/share/eeepc-acpi-scripts/functions.sh
machine:~# set -x
machine:~# detect_x_display
+ detect_x_display
+ local _user
+ local _home
++ sed -n '/ (:0[\.0]*)$\| :0 /{s/ .*//p;q}'
++ who
+ _user=joe
+ '[' joe = '' ']'
++ cut -d: -f6
++ getent passwd joe
+ _home=/home/joe
+ XAUTHORITY=/home/joe/.Xauthority
+ '[' -f /home/joe/.Xauthority ']'
+ export XAUTHORITY
+ export DISPLAY=:0
+ DISPLAY=:0
+ user=joe
+ home=/home/joe
I just noticed that DebPkg:eeepc-acpi-scripts 1.1.11 was uploaded. I
upgraded and rebooted but the problem is still the same. Besides that
the path changed to the following.
/usr/share/acpi-support/eeepc-acpi-scripts/lib/functions.sh
Manually exporting the appropriate setting and calling `xrandr` does not
(of course) work either.
$ sudo su -
machine:~# export XAUTHORITY=/home/paul/.Xauthority
+ export XAUTHORITY=/home/joe/.Xauthority
+ XAUTHORITY=/home/joe/.Xauthority
machine:~# export DISPLAY=:0
+ export DISPLAY=:0
+ DISPLAY=:0
machine:~# xrandr -q
+ xrandr -q
No protocol specified
Can't open display :0
Thanks,
Paul
Ben Armstrong
> $ sudo su -
> machine:~# export XAUTHORITY=/home/paul/.Xauthority
> + export XAUTHORITY=/home/joe/.Xauthority
> + XAUTHORITY=/home/joe/.Xauthority
> machine:~# export DISPLAY=:0
> + export DISPLAY=:0
> + DISPLAY=:0
> machine:~# xrandr -q
> + xrandr -q
> No protocol specified
> Can't open display :0
Huh? It says paul in your export and joe in the set -x output. What's
up with that? Editing mistake? For comparison, from my system:
root@shade:~# export XAUTHORITY=/home/synrg/.Xauthority
root@shade:~# export DISPLAY=:0
root@shade:~# xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis)
220mm x 129mm
1024x600 60.0*+ 65.0
800x600 60.3
640x480 59.9
I think we've established you have a local Xorg configuration problem
here and there is no bug in eeepc-acpi-scripts. Perhaps your
.Xauthority file has wrong ownership or something? It should be owned
by the user it belongs to.
Paul Menzel
> On 12/11/10 12:08 PM, Paul Menzel wrote:
> > $ sudo su -
> > machine:~# export XAUTHORITY=/home/paul/.Xauthority
> > + export XAUTHORITY=/home/joe/.Xauthority
> > + XAUTHORITY=/home/joe/.Xauthority
> > machine:~# export DISPLAY=:0
> > + export DISPLAY=:0
> > + DISPLAY=:0
> > machine:~# xrandr -q
> > + xrandr -q
> > No protocol specified
> > Can't open display :0
>
> Huh? It says paul in your export and joe in the set -x output. What's
> up with that? Editing mistake?
Unfortunately the latter. So much for obfuscating and trying to get my
username out there. ;-) That search in Evolution’s message editor does
not start over at the beginning and just goes on from the cursor.
> For comparison, from my system:
>
> root@shade:~# export XAUTHORITY=/home/synrg/.Xauthority
> root@shade:~# export DISPLAY=:0
> root@shade:~# xrandr -q
> Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
> VGA1 disconnected (normal left inverted right x axis y axis)
> LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis)
> 220mm x 129mm
> 1024x600 60.0*+ 65.0
> 800x600 60.3
> 640x480 59.9
What display manager and DE are you using?
> I think we've established you have a local Xorg configuration problem
> here and there is no bug in eeepc-acpi-scripts. Perhaps your
> .Xauthority file has wrong ownership or something? It should be owned
> by the user it belongs to.
It is owned by by my user.
$ ls -l /home/paul/.Xauthority
-rw------- 1 paul paul 1238 12. Nov 00:15 /home/paul/.Xauthority
I will try to investigate further on the weekend.
Thanks,
Paul
Ben Armstrong
> What display manager and DE are you using?
gdm3 and LXDE (openbox).
> It is owned by by my user.
>
> $ ls -l /home/paul/.Xauthority
> -rw------- 1 paul paul 1238 12. Nov 00:15 /home/paul/.Xauthority
OK. This is very strange:
synrg@shade:~$ su -
Password:
root@shade:~# xeyes # a nice quick test if display works :)
root@shade:~# xauth
Using authority file /var/run/gdm3/auth-for-synrg-MXsbdM/database
xauth> exit
root@shade:~# export XAUTHORITY=/dev/null
root@shade:~# xauth
Using authority file /dev/null
xauth> exit
root@shade:~# xeyes # even after pointing at a
# bogus XAUTHORITY, xeyes still shows!
# say what?
Paul Menzel
> On 12/11/10 12:34 PM, Paul Menzel wrote:
> > What display manager and DE are you using?
>
> gdm3 and LXDE (openbox).
>
> > It is owned by by my user.
> >
> > $ ls -l /home/paul/.Xauthority
> > -rw------- 1 paul paul 1238 12. Nov 00:15 /home/paul/.Xauthority
>
> OK. This is very strange:
>
> synrg@shade:~$ su -
> Password:
> root@shade:~# xeyes # a nice quick test if display works :)
> root@shade:~# xauth
> Using authority file /var/run/gdm3/auth-for-synrg-MXsbdM/database
> xauth> exit
> root@shade:~# export XAUTHORITY=/dev/null
> root@shade:~# xauth
> Using authority file /dev/null
> xauth> exit
> root@shade:~# xeyes # even after pointing at a
> # bogus XAUTHORITY, xeyes still shows!
> # say what?
Thank you for your test case. I discovered this works for me too until I
run `detect_x_display`.
$ sudo su -
machine:~# xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096
VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 337mm x 270mm
1280x1024 75.0* 60.0
1024x768 75.1 75.0 70.1 60.0
832x624 74.6
800x600 72.2 75.0 60.3 56.2
640x480 72.8 75.0 66.7 60.0
720x405 70.0
720x400 70.1
LVDS1 connected (normal left inverted right x axis y axis)
800x480 60.0 +
640x480 85.0 72.8 75.0 59.9
720x400 85.0
640x400 85.1
640x350 85.1
TV1 disconnected (normal left inverted right x axis y axis)
machine:~# . /usr/share/acpi-support/eeepc-acpi-scripts/lib/functions.sh
machine:~# xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096
VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 337mm x 270mm
1280x1024 75.0* 60.0
1024x768 75.1 75.0 70.1 60.0
832x624 74.6
800x600 72.2 75.0 60.3 56.2
640x480 72.8 75.0 66.7 60.0
720x405 70.0
720x400 70.1
LVDS1 connected (normal left inverted right x axis y axis)
800x480 60.0 +
640x480 85.0 72.8 75.0 59.9
720x400 85.0
640x400 85.1
640x350 85.1
TV1 disconnected (normal left inverted right x axis y axis)
machine:~# detect_x_display
machine:~# xrandr
No protocol specified
Can't open display :0
Now I compared the environment variables before and after running
`detect_x_display`. `XAUTHORITY` is set to som
machine:~# env | grep XAUTHORITY
XAUTHORITY=/var/run/gdm3/auth-for-paul-Hwcbtn/database
machine:~# detect_x_display
machine:~# env | grep XAUTHORITY
XAUTHORITY=/home/paul/.Xauthority
machine:~# ls -l /var/run/gdm3/auth-for-paul-Hwcbtn/database
-rw------- 1 paul paul 52 13. Nov 05:27 /var/run/gdm3/auth-for-paul-Hwcbtn/database # probably created at login time
machine:~# ls -l /home/paul/.Xauthority
-rw------- 1 paul paul 106 13. Nov 05:29 /home/paul/.Xauthority
Thanks,
Paul
Ben Armstrong
simply a bad idea (to try to talk to X from acpi scripts). I've heard
this advice before and given the difficulty we've had, I have to wonder
if it isn't time to finally take that seriously. After all, this key
sends an XF86Display event, so the WM should bind that to do whatever
the user wants. I think in GNOME and KDE, there should be some agent
that already handles this. For non-gnome/kde, something could be
cobbled together with xrandr the way we do already, only not running as
root.
I'm going to see what other keys (if any) rely on detect_x_display, and
see if we can apply the same approach.
Paul Menzel
> After discussing this with a member of the X team, they advise this is
> simply a bad idea (to try to talk to X from acpi scripts). I've heard
> this advice before and given the difficulty we've had, I have to wonder
> if it isn't time to finally take that seriously. After all, this key
> sends an XF86Display event, so the WM should bind that to do whatever
> the user wants. I think in GNOME and KDE, there should be some agent
> that already handles this. For non-gnome/kde, something could be
> cobbled together with xrandr the way we do already, only not running as
> root.
>
> I'm going to see what other keys (if any) rely on detect_x_display, and
> see if we can apply the same approach.
Thank you Ben for looking into this. If you need help with for example
filing bug reports upstream or with testing, please say so.
Thanks,
Paul
PS: I want to thank Ben and Luca and everybody else for getting 1.1.11
out and for your support on the list and your work with the Wiki.
PPS: Ben, I am still wondering why it works for you. Did my last example
(running `dectect_x_display` before) also fail for you?
Damyan Ivanov
> After discussing this with a member of the X team, they advise this is
> simply a bad idea (to try to talk to X from acpi scripts). I've heard
> this advice before and given the difficulty we've had, I have to wonder
> if it isn't time to finally take that seriously.
Before going there, maybe we could try using getXconsole from
/usr/share/acpi-support/power-funcs ? There are other useful scripts
in that directory, for example screenblank.
Luca Niccoli
> I'm going to see what other keys (if any) rely on detect_x_display, and
> see if we can apply the same approach.
Now that acpi-support x detection has been fixed, we really should
rely on it instead of on our own (broken) routine.
Cheers,
Luca
Luca Niccoli
Should I commit it any way?
It's just a bit more than search and replace (detect_x_display also
exported $user - while getXconsole exports $USER - and $home - but it
doesn't seem used anywhere)
Ben Armstrong
> I have a changeset ready but will not be able to try it in the next few days.
> Should I commit it any way?
please do.
> It's just a bit more than search and replace (detect_x_display also
> exported $user - while getXconsole exports $USER - and $home - but it
> doesn't seem used anywhere)
> Cheers,
sounds good to me.
Ben
Luca Niccoli
sets the former as well as the latter.
Committed.
Luca
Paul Menzel
Am Freitag, den 26.11.2010, 18:24 +0100 schrieb Luca Niccoli:
> Well, it wasn't even necessary to change $user to $XUSER, getXconsole
> sets the former as well as the latter.
>
> Committed.
I just upgraded DebPkg:eeepc-acpi-scripts from 1.1.10 to 1.1.11 and the
problem is still present, i. e. changing the output with Fn + F2 works
in GDM3 but does not with LXDE. The version of DebPkg:acpi-support is
0.138-7.
Should this bug be reassigned to DebPkg:acpi-support?
Thanks,
Paul