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)
bamse has quit [Server closed connection]
bamse has joined #aarch64-laptops
bamse is now known as Guest287
_whitelogger has joined #aarch64-laptops
Mathew has quit [Server closed connection]
Mathew has joined #aarch64-laptops
<gwolf>
calebccff: That's where I found it at least!
<gwolf>
steev: Under pwd/sys/devices/platform/soc@0/8c0000.geniqup/884000.i2c/i2c-1/1-0070/power_supply I have two devices -- yoga-c630-adapter and yoga-c630-battery
rfs613 has quit [Server closed connection]
rfs613 has joined #aarch64-laptops
CosmicPenguin has quit [Server closed connection]
CosmicPenguin has joined #aarch64-laptops
<steev>
Ah, so it’s working for you :)
<steev>
Also… I figured out my next issue. It doesn’t like efi_zboot
<ardb>
it will work if you put the "ARM\x64" magic number in the zboot header
<init>
with 6.1-rc7 I don't have a display if my power cord is not plugged in. Haven't had time to debug, but it makes no difference if I boot with or without it. It needs to be plugged in.
<init>
on x13s. of course.
<init>
X will start with the xf86-video-fbdev driver for now.
<init>
battery level is now also missing (from 6.0-rc4), so that might all be related
<init>
but like I said, I had about 10 minutes of testing since booting it yesterday
<steev>
definitely don't experience that here
<steev>
but i'm using wayland, not x, so not sure
<steev>
i'd check the xorg log, i'm assuming it's something modesetting related
<steev>
iirc, we saw some issues with hyper-v not being able to start x on kali too and it's due to the modesetting not working anymore and having to force fbdev
<init>
quickly looking at it, it's quite weird that X started in fact :>. I have a "wayland conditions error" that seems to prevent wayland from starting
<steev>
maybe an llvm change and it dislikes the new llvmpipe/mesa stuff?
<init>
dunno. I'll turn on debugging and look at the logs.
<steev>
that would be good to get :)
<init>
I ran a very custom kernel config, just so I can get to learn a bit more about this platform. I took back a working config from 6.0-rc4 and I'm building a version out of it. Lazyest way to figure out if I messed up something, before digging.
aceridus has joined #aarch64-laptops
<steev>
when it would go to start X, would you essentially just have a cursor in the upper left corner?
<init>
it just basically skips wayland for some execution conditions reasons, and starts X successfully.
<init>
even if I force wayland in every single way i can
<init>
now back to breaking it with custom patches!
<init>
Now what I sort of was forced to try it for a day or two, X11 definitely runs way smoother than Wayland on software rendering.
<init>
on that hardware
<init>
not that i'm a big fan of the past, but as we're waiting for some sort of gpu support, that's not a bad alternative
<steev>
Okay, 6.0.10 pushed, tagged as lenovo-x13s-6.0.10,
<steev>
Includes the audio bits
<steev>
You’ll need the firmware, and I’m not sure if the ucm2 bits have been pushed out yet
<bamse>
steev: not sure if i complained to you about the x13s caps-as-ctrl didn't work properly...booted windows and let it do a few firmware upgrades, now it does work as i want it to
<bamse>
steev: problem before was if i hit caps+<c, c> i wouldn't get two ^C, i would get ^C c
<steev>
I think I remember something like that
<bamse>
should have listened to you and done the upgrade ealier ;)
<steev>
:D
<steev>
they've done a pretty decent job staying on top of bugs with the x13s
<steev>
which makes me happy compared to... other devices bugs in their firmware
<clover[m]>
<steev> "Includes the audio bits" <- are you telling me audio works now?!
<clover[m]>
is christmas early
<steev>
i said it includes them
<steev>
i didn't say it works
<steev>
it doesn't work for me, but maybe others will, and we can figure out what the difference is
<clover[m]>
lol ok, will try after work
<steev>
assuming the ucm2 stuff is available somewhere
<steev>
but lets see if it even works for people, and doesn't just probe defer :D
<steev>
there are new config options needed for it
<steev>
bamse: since you're around... if gmu is throwing -13... what did i screw up?
da_snowbird has quit [Quit: Vision[]: i've been blurred!]
<steev>
i bet it's something silly like, i left the amd,imageon compatible in the
<bamse>
steev: i seem to get the same if mdss probe deferred...
<javierm>
steev: I would guess that there's some error in the runtime pm usage. Maybe some PM usage count is not properly decremented in the probe deferral path?
<javierm>
steev: that will only show something if the probe deferral timeout didn't expire
<javierm>
I really don't like that new probe deferral timeout behaviour :(
<bamse>
steev: i've not seen any update on the board file front...did poke the discussion before i went on vacation though
<steev>
i would assume it would continueto show as long as the device is deferred
<steev>
vacation smh... you europeans and your lack of work ethics :P
<javierm>
steev: that was my assumption to. But I learned the other day digging on the display issue that's not the case
<steev>
javierm: that gives me something to look around, i didn't notice that earlier, thanks for pointing it out
<javierm>
steev: because if timeouts, then the device model assumes that the probe "failed" with a normal errno code...
<steev>
javierm: hm, so is there a way to tell if it's actually still deferred?
<javierm>
steev: no that I know of
<javierm>
steev: in other words, there's no way to distinguish between a driver's probe that failed and one that failed because the probe deferral mechanism just timed out
<bamse>
steev: was 8 years since we visisted sweden last, so it was time... :)
<steev>
enjoy :)
<steev>
javierm: erk
<steev>
that's not very good
<bamse>
steev: i did enjoy it, got back last night
<steev>
ahh
<steev>
i miss ostkaka :(
<javierm>
steev: what you can do though is boot with deferred_probe_timeout=60 or something and then you will prevent the timeout and see what was deferred and why
<bamse>
steev: sweden was kind to remind me how miserable the weather is...even got a couple of inches of snow last weekend...and then back to rain
<steev>
javierm: good point, i guess i can try that - i was thinking also just disable runtime pm to see
<steev>
javierm: it's still gone
<steev>
once it hits 3.11, the deviceis either there?
<javierm>
steev: so nothing from /sys/kernel/debug/devices_deferred even without the timeout?
<bamse>
steev: does your interest in this indicate that there has been any updates on the subject?
<bamse>
steev: or you just rebased the old patches?
<steev>
rebased old patches, hoping that the various other lower level fixes have helped
<steev>
but i feel like i'm missing a patch or two somewhere
<steev>
my patchsets director(y|ies) have a bit over 3000 patches though, so gotta clean that up to just the stuff i really want
<bamse>
you should be able to get away with far fewer patches these days ;)
<steev>
oh i know :) it's just stuff like, these were applied to 6.1, then these ones, then these ones
<steev>
anywho, i'll be back a bit later
<steev>
gotta celebrate the USA win
<bamse>
robclark: we seem to have unbalanced pm_runtime in the gpu in the case that mdss probe defers, we had a patch for this a few months back, but i don't see it in the git log...do you remember?