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