ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
iivanov has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
macc24 has joined #aarch64-laptops
hightower2 has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
hightower2 has joined #aarch64-laptops
macc24 has quit [Ping timeout: 480 seconds]
hightower2 has quit [Ping timeout: 480 seconds]
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
macc24 has joined #aarch64-laptops
macc242 has joined #aarch64-laptops
macc24 has quit [Ping timeout: 480 seconds]
macc242 has quit []
macc242 has joined #aarch64-laptops
<steev> 5.15 is out
Lucanis has quit [Remote host closed the connection]
Lucanis has joined #aarch64-laptops
<steev> audio is broken for me but i think it's the weird pulseaudio changes not kernel side
macc242 has quit [Ping timeout: 480 seconds]
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
<bamse> steev: so the reason why the touchpad stops working is that libinput relates it to the SW_LID...which we seem to not always (or even rarely) get the falling interrupt for
<steev> that is... very weird
<bamse> steev: so libinput is convinced that the lid is still closed...
<steev> is it a bug in libinput then? i don't even know how to find the SW_LID since we're not acpi
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
<bamse> steev: it's a gpio-keys, just registering an irq handler on gpio 124
<steev> ah, that one
<steev> would be nice if we could actually label it a lid switch, so end users can see it
<bamse> looking at the gpio state it's low, but running evtest tells me that SW_LID is high
<bamse> it's named "lid"
<bamse> but it's exposed to userspace as gpio-keys...with SW_LID and SW_TABLET_MODE exposed
<steev> i kinda mean the name since the other stuff has names
<steev> N: Name="hid-over-i2c 6243:0001 Keyboard"
<steev> as an example
<bamse> ahh, not sure what we should name it...unless we create one per thing
<bamse> well i do believe it's actually gpio signals from the EC
derzahl has quit [Ping timeout: 480 seconds]
<steev> so ec driver coming soon? :P
iivanov_ has quit [Remote host closed the connection]
<bamse> well, robert merged the backlight series into drm-misc-next (or whatever that branch is called)
<bamse> so the only thing left in my tree would then be the battery driver...so it would certainly be nice to come up with an acceptable design for that
<steev> :D
<steev> wait, the backlight part of the dts or just the driver portion
<bamse> he picked the driver portion, i've yet to send the dts patches again
<bamse> and it doesn't seem like it's perculated up to linux-next yet, so i presume we'll get that after the merge window
<steev> ah dang, was hoping 5.16 would be "good enough"
<steev> i'm hoping lumag is able to track down that clk rcg issue
<steev> that patch he provided does help quite a bit
<steev> and the guy who is bm16ton emailed me on friday, he asked about the blue screen as well, i haven't replied to him yet
<bamse> i wasn't sure the two issues where related...but looking at the log where i just got it seems quite likely
<steev> it started in 5.12 but was *extremely* rare, 5.13 became more common