Ticket #2209 (new defect)

Opened 6 years ago

Last modified 5 years ago

alsactl restore wakes up X

Reported by: lindi Owned by: openmoko-kernel
Priority: low Milestone: stable-kernel-2009.1
Component: kernel Version:
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

Steps to reproduce:
1) alsactl -f stereout.state restore
2) xset s 10 5
3) wait for X to turn display off
4) alsactl -f gsmhandset.state restore

Expected results:
4) alsactl changes sound configuration but does not affect display

Actual results:
4) display is turned on

More info:
1) strace shows that xserver-xglamo reads one byte from fd 0
   (/dev/tty2) when alsactl is ran:

13:09:39.424700 gettimeofday({1231844979, 425590}, NULL) = 0
13:09:39.427042 --- SIGALRM (Alarm clock) @ 0 (0) ---
13:09:39.429421 --- SIGIO (I/O possible) @ 0 (0) ---
13:09:39.430684 read(0, "w"..., 256)    = 1
13:09:39.435815 gettimeofday({1231844979, 436702}, NULL) = 0
13:09:39.438910 read(0, 0x3ff28a0, 256) = -1 EAGAIN (Resource temporarily unavailable)
13:09:39.441274 read(5, 0x13c5a4, 256)  = -1 EAGAIN (Resource temporarily unavailable)
13:09:39.445092 ioctl(6, EVIOCGVERSION, 0x3ff28b4) = 0
13:09:39.448269 ioctl(6, 0x80204520, 0x3ff28b0) = 4
13:09:39.450572 ioctl(6, 0x80404523, 0x3ff28a8) = 8

2) Switching to gsmhandset.state seems to always write "w" and
   switching to stereout.state seems to write "\367". Any idea where
   these values come from?

Change History

comment:1 Changed 6 years ago by sushama

Kernel Version:kernel - 2.6.28-stable+gitr0e5fe639e234cdeb11d8441f19c5b3109a8b6a17-r2 -
Steps:
1)export DISPLAY=:0
2)alsactl -f stereoout.state restore
3)xset s 10 5


4)alsactl -f gsmhandset.state restore
--Display stays OFF,verify alsa file was loaded
5)alsactl -f testing.state store


6)diff -ur testing.state gsmhandset.state
---Check if testing.state and gsmhanset.state have any difference in the file
We cannot reproduce the bug and would close it unless you provide more information

comment:2 Changed 6 years ago by lindi

Huh, I seem to have forgotten to mention what kernel version I was running. It was andy-tracking b8b36e5ec3db71d5. I'll try newer andy-tracking soon and if that fails I'll try stable as well.

comment:3 Changed 6 years ago by lindi

This still happens with andy-tracking 81da012eb0fff1bc. sushama, are you running any other processes that could control display brightness? Do you see the characters being read with strace? If I "chvt 1" I can see that "[P" is written to console when I switch to gsmhandset.state.

comment:4 Changed 6 years ago by joerg

wakeup also happens without X running, e.g on FSO-console.
Traced down (one?) reason to be changing alsa control.66/67 'Capture Right Mixer' (/Left)

reproduce:
FSO-console MS5, log in via ssh, start alsamixer, wait until screen goes dark, tweak
'Capture Right Mixer' -> screen comes up again.
(this been tested on GSM-FW uSD image)

Note there's another bug in alsa implementation of control.66/7
Maybe this one a side effect

comment:5 Changed 6 years ago by joerg

btw as it is triggered by *change* of control.66, repeated restoring of gsmhandset.state will produce the effect only on first action.
It's not alsactl that is triggering this, it's the _change_ of some mixer controls.

Verified by repeated
"alsactl restore -f gsmhandset.state"
and an occasional
"alsactl restore -f mymodified-foo.state"

comment:6 Changed 6 years ago by andy

I think to wake up framebuffer, something is likely generating an input event.

The two things floating around we generate input events for there are headphone and HOLD.

I wonder if when we select the Capture action, we power MICBIAS, and we see a HOLD event or by another path headphone event.

You can confirm it by hexdumping the appropriate /dev/input/event and then doing the alsamixer.

comment:7 Changed 6 years ago by lindi

Thanks,

fd = os.open("/dev/input/event4", os.O_NONBLOCK | os.O_RDONLY)
fcntl.ioctl(fd, 0x40044590, 1) # EVIOCGRAB

seems to be a temporary userland fix that prevents X and tty from seeing this event. (They won't see AUX or POWER either obviously.)

When I switch from gsmhandset to stereoout I see keycode 119 release. When I do the opposite I see keycode 119 press.

comment:8 Changed 6 years ago by andy

Yeah 119 is KEY_PAUSE which is HOLD key event.

HOLD key is not super useful anyway because it only works with headset plugged in and MICBIAS powered. I assume headset isn't in during these tests.

What we could try to do is mask HOLD events by tracking headset JACK presence, that'd take this away for normal case headset isn't in.

comment:9 Changed 6 years ago by joerg

Internal power management of ALSA WM8753 driver enables and disables MICBIAS depending on setting of control.66.
MICBIAS triggers HOLD.

When pressing and holding down HOLD-button of an attached headset, IRQ generation and screen wakeup via control.66 as well as 'alsactl restore' is stopped.

Masking HOLD-IRQ by tracking JACK_INSERT seems to be the best way fix this

comment:10 Changed 5 years ago by arhuaco

  • Priority changed from normal to low
  • Milestone set to stable-kernel-2009.1
Note: See TracTickets for help on using tickets.