[SOLVED] ACPI daemon can't open display unless restarted

tlawson · 2009-01-24 03:27:24

I'm trying to set up a machine to have X rotate the screen (using xrandr) on an ACPI event. (It's a tablet PC.)

The rotation script works fine, and gets called properly on the ACPI event, but when xrandr is called it outputs "Cannot open display" to stderr.

The odd thing is this: If I restart the acpi daemon, the whole thing works seamlessly, even after killing and restarting X. Does anybody have any idea why this would be so?

Last edited by tlawson (2009-01-25 12:40:07)

kludge · 2009-01-24 04:50:33

i don't know *exactly* why this is the case, back to x from a vc, i get:

Jan 23 14:22:20 laura acpid: client connected from 5606[0:100]
Jan 23 14:22:20 laura acpid: 1 client rule loaded

in my acpid log, where 5606 is the process for x. do you have these messages?

can you post the script you're using?

tlawson · 2009-01-24 06:21:17

I do, indeed, get such messages. The only differences I can see are the following. Here's the initial startup:

Jan 24 00:11:30 malachite acpid: client connected from 2096[82:82]
Jan 24 00:11:30 malachite acpid: 1 client rule loaded
Jan 24 00:12:16 malachite acpid: client connected from 2315[0:1000]
Jan 24 00:12:16 malachite acpid: 1 client rule loaded

(2096 = HAL, 2315 = X)

Here's what I get when restarting acpid:

Jan 24 00:14:08 malachite acpid: client connected from 2315[0:1000]
Jan 24 00:14:08 malachite acpid: 1 client rule loaded
Jan 24 00:14:12 malachite acpid: client connected from 2096[82:82]
Jan 24 00:14:12 malachite acpid: 1 client rule loaded

Could it be related to HAL/X connecting in the opposite order?

The rotation script includes a lot of noise about setting the Wacom device properly and checking the hardware's tablet/laptop state. The behavior is replicable just by adding the following to /etc/acpi/handler.sh:

    ibm/hotkey)
        case "$2" in
            HKEY)
                case "$4" in
                    00001004)
                        #echo "Sleep button pushed!">/dev/tty5
                        pm-suspend
                    ;;
                    00005009)
                        #echo "Tablet swivel down!">/dev/tty5
                        #/usr/local/bin/autorotate
            xrandr -o left
                    ;;
                    0000500a)
                        #echo "Tablet swivel up!">/dev/tty5
                        #/usr/local/bin/autorotate
            xrandr -o normal
                    ;;
                esac
                ;;
        esac
        ;;

kludge · 2009-01-24 20:29:54

tlawson wrote:

Here's what I get when restarting acpid:
Code:
Jan 24 00:14:08 malachite acpid: client connected from 2315[0:1000]
Jan 24 00:14:08 malachite acpid: 1 client rule loaded
Jan 24 00:14:12 malachite acpid: client connected from 2096[82:82]
Jan 24 00:14:12 malachite acpid: 1 client rule loaded
Could it be related to HAL/X connecting in the opposite order?

i don't *know*, because i don't use hal, i'd say that's a good guess. however as far as i understand, hal is only handly input devices for x.

here's a couple other things to try. with xrandr, you can specify exactly which device to manipulate. also, verbose flags are *always* good for debugging. so try changing your 'xrandr' invocations to:

xrandr --verbose -d $DISPLAY -o left

it's also possible that the event handler is being called by acpi before X has reconnected. that might explain why the display cannot be opened. try adding

logger "tablet swivel event received"

in the swivel events and you'll see in your logs where the swivel action gets called in relation to the acpi client connects.

if that's the problem, a cheap work-around would be to add 'sleep' to the handler to wait for the display to become available. a better work around would be to create a conitional wait-state until the dispay is available.

mind you, those are only work-arounds.

anrxc · 2009-01-24 20:41:35

tlawson wrote:

If I restart the acpi daemon, the whole thing works seamlessly, even after killing and restarting X. Does anybody have any idea why this would be so?

Your DISPLAY and XAUTHORITY are emtpy on boot, read this topic from a few days back and you will understand: http://bbs.archlinux.org/viewtopic.php? … 74#p483874

tlawson · 2009-01-25 12:39:49

anrxc wrote:

tlawson wrote:
If I restart the acpi daemon, the whole thing works seamlessly, even after killing and restarting X. Does anybody have any idea why this would be so?
Your DISPLAY and XAUTHORITY are emtpy on boot, read this topic from a few days back and you will understand: http://bbs.archlinux.org/viewtopic.php? … 74#p483874

Ah, now I feel stupid; of course these aren't set if acpid is launched before X. Changing the code to

XAUTHORITY="/home/user/.Xauthority" DISPLAY=":0.0" /usr/local/bin/autorotate

makes it work perfectly, at least if user launched X. Thank you.

kludge · 2009-01-25 18:48:32

@tlawson: glad you found a fix!

@anrxc: something seems wrong about hardcoding a particular user's /home directory into a system-wide configuration file. at the least, it's inelegant and inflexible. at the worst, i'd imagine it could introduce significant security holes.

Last edited by kludge (2009-01-25 20:17:06)

tlawson · 2009-01-25 20:09:57

kludge wrote:

@anrxc: sorry seems wrong about hardcoding a particular user's /home directory into a system-wide configuration file. at the least, it's inelegant and inflexible. at the worst, i'd imagine it could introduce significant security holes.

I'd actually like to know a more elegant solution myself. Of course I could start X at boot, but I prefer to be able to stay at the console unless necessary.

anrxc · 2009-01-25 20:56:02

kludge wrote:

@anrxc: something seems wrong about hardcoding a particular user's /home directory into a system-wide configuration file. at the least, it's inelegant and inflexible. at the worst, i'd imagine it could introduce significant security holes.

I said "Your DISPLAY and XAUTHORITY are emtpy on boot". I didn't propose what he should do. Fortunately this is not a configuration file but a shell script so for one solution there are ways to find who is running an X server and on which display etc. (i.e. for reference he could check certain laptop-mode-tools modules). The user in the other topic was locking the display, and he was doing it with super users priviledges. Then for "security" reasons he employed sudo, so while he hardcoded the user there, he could as well do it for his XAUTHORITY.

kludge · 2009-01-26 00:35:55

@anrxc: sorry to misdirect my criticism. no hard feelings?

@all: so, a little research reveals that these lines:

Jan 24 00:14:08 malachite acpid: client connected from 2315[0:1000]
Jan 24 00:14:08 malachite acpid: 1 client rule loaded
Jan 24 00:14:12 malachite acpid: client connected from 2096[82:82]
Jan 24 00:14:12 malachite acpid: 1 client rule loaded

mean that those processes are listening to /var/run/acpid.socket.

from 'man acpid':

In addition to rule files, acpid also accepts connections on a UNIX
domain socket (/var/run/acpid.socket by default). Any application may
connect to this socket. Once connected, acpid will send the text of
all ACPI events to the client. The client has the responsibility of
filtering for messages about which it cares.

this is neat, because the problem with your original 'xrandr' invocations from '/etc/acpid/handler.sh' is that they're run by root in acpid's environment, where XAUTHORITY and DISPLAY are unset. if they were called by some event handler operating *within* the x server's scope, there'd be no need for ugly hacks to get the DISPLAY. so the question is, how do you get x to listen for "ibm/hotkey HKEY 00000080 {00005009,0000500a}".

i haven't found a really good answer yet, but the last post in this thread has an interesting suggestion:

http://ubuntuforums.org/showthread.php?t=651248

if you could get it generate a keycode, and verify that x receives that with 'xev', then you can configure x or your wm to respond to. the advantage to having x respond directly is that you have the keycode bound in a system-wide x configuration so that you could have multiple x sessions running and they'd *all* respond to the swivel actions. and on the console, it would do... nothing! it might even make more sense to handle the event in '/etc/acpi/events/' than in the all-purpose handler.

and, i did some googling and found these for you, which i hope help:

http://www.krizka.net/2008/02/13/thinkp … der-linux/
http://ubuntuforums.org/showthread.php?t=604896

you did google "your-tablet swivel rotate x", right? :b

tlawson · 2009-01-26 02:24:56

this is neat, because the problem with your original 'xrandr' invocations from '/etc/acpid/handler.sh' is that they're run by root in acpid's environment, where XAUTHORITY and DISPLAY are unset. if they were called by some event handler operating *within* the x server's scope, there'd be no need for ugly hacks to get the DISPLAY. so the question is, how do you get x to listen for "ibm/hotkey HKEY 00000080 {00005009,0000500a}".

That's a good point - thanks for the hint. I'll see if I can make any sense of the xserver's socket code.

and, i did some googling and found these for you, which i hope help:
http://www.krizka.net/2008/02/13/thinkp … der-linux/
http://ubuntuforums.org/showthread.php?t=604896
you did google "your-tablet swivel rotate x", right? :b

well, so I wrote the second one, which unfortunately outs me as just some idiot who's trying to migrate from Ubuntu/Gnome. It appears that it works there - accidentally - because they start the display manager very early. sorry to waste everybody's time.

kludge · 2009-01-26 02:31:52

no worries... i actually had fun with this one, and learned a bit.

p.s.: further investigation seems to show that there is no x equivalent of acpi_listen. it looks like it's up to individual drivers (e.g.: evdev, xf86-video-intel, etc.) to handle acpi events. which suggests that you might have to an x.org module to get that idea to work. if you do, you're my hero.

Arch Linux

#1 2009-01-24 03:27:24

[SOLVED] ACPI daemon can't open display unless restarted

#2 2009-01-24 04:50:33

Re: [SOLVED] ACPI daemon can't open display unless restarted

#3 2009-01-24 06:21:17

Re: [SOLVED] ACPI daemon can't open display unless restarted

#4 2009-01-24 20:29:54

Re: [SOLVED] ACPI daemon can't open display unless restarted

#5 2009-01-24 20:41:35

Re: [SOLVED] ACPI daemon can't open display unless restarted

#6 2009-01-25 12:39:49

Re: [SOLVED] ACPI daemon can't open display unless restarted

#7 2009-01-25 18:48:32

Re: [SOLVED] ACPI daemon can't open display unless restarted

#8 2009-01-25 20:09:57

Re: [SOLVED] ACPI daemon can't open display unless restarted

#9 2009-01-25 20:56:02

Re: [SOLVED] ACPI daemon can't open display unless restarted

#10 2009-01-26 00:35:55

Re: [SOLVED] ACPI daemon can't open display unless restarted

#11 2009-01-26 02:24:56

Re: [SOLVED] ACPI daemon can't open display unless restarted

#12 2009-01-26 02:31:52

Re: [SOLVED] ACPI daemon can't open display unless restarted

Board footer