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)
<gwolf>
bamse: re: backlight regulator and camera -- It kind of makes sense, doesn't it? AIUI, some systems have automated backlight depending on the luminity of the surroundings... and that information can be gathered via the camera
<bamse>
gwolf: hmm, that would be nice...don't know if we have that ability
<gwolf>
no, I just mean that it makes sense for the camera to power when the backlight controls do
<bamse>
well, yeah in that direction...but it's not as obvious in the other direction
<bamse>
i.e. that we should turn off camera just because the backlight goes off
<bamse>
consider the case where you're in a video call and the backlight turns off because your browser didn't inhibit dpms properly...then your usb camera is disconnected, and at best the others in the call will see your camera die
<bamse>
at worst your browser crashes, because you wheren't supposed to disconnect your video device mid-stream
<bamse>
on the other hand, that might be considered a privacy feature ;)
<gwolf>
(-: That's a bug in the browser, don't sweat about it...
<gwolf>
learn to assign blame to the proper places ;-)
<gwolf>
I usually have two webcams on my work laptop. I recently noticed that, if the external webcam (my usual favorite) gets connected when the browser is already using the internal one, it switches automagically!
<gwolf>
I liked it.
<gwolf>
I am not used for magic to work in my favor.
<bamse>
gwolf: of course, but i can fix the kernel...i don't know where to start with browser bugs
<bamse>
that's quite fancy, it's nice when such magic works in ones favour :)
<gwolf>
bamse: absolutely, hats off for you :-}
<HdkR>
Ampere Siryn is supposed to be sampling now isn't it? Or was it delayed?
<HdkR>
Or am I mixing that up with AltraMax?
wwilly has quit [Ping timeout: 480 seconds]
<maz>
I though Siryn was targeting 2024, or something like that...
<maz>
well, if they do, I'll be pleasantly surprised.
<HdkR>
:)
<HdkR>
Hoping for another workstation platform as well. I don't have room to acoustically isolate a rackmount server atm
<maz>
I've been considering an Altra as a workstation. something like e252-p30 should be easy to tame noise wise.
<HdkR>
Looks like Avantek doesn't offer the AltraMax in the workstation form factor
<maz>
on the other hand, given that the M1 runs rings around N1 for the workloads I'm interested in, maybe I'll just wait for a fruity machine with 16/32 CPUs...
<arnd>
The new Altra workstation from ADLink/IPI (https://www.ipi.wiki/pages/com-hpc-altra) looks a bit nicer and more affordable for a workstation build than the Gigabyte/Avantek workstation.
<arnd>
not sure if that one will be offered with more than 32 cores, I'm considering it as a replacement for my aging TR1950X, but it feels like a downgrade
<maz>
no price tag?
<maz>
and I guess it is the 1.7GHz part.
<arnd>
I think they are still working on the pricing, but I'm fairly sure this is the lowest-spec CPU. It's really annoying that they run the parts with fewer cores at the lowest clock rate, rather than the opposite as everyone else does
<arnd>
apparently you can buy that board with the 80-core CPU, but they are not advertising that in combination with the carrier and workstation case
<maz>
64 cores at 2.8 would be my sweet spot when it comes to this type of machine. the low-end spec is pretty uninteresting...
<arnd>
Agreed. The 32-core version is probably usable as a desktop, but it won't compete against a mass-market Ryzen 59xx on price or performance. The 64-core version may hold up against a current Threadripper Pro or Cascade-Lake chips with similar thread count and cost.
<gwolf>
arnd: I think holding a Threadripper as a general-purpose desktop system is pushing it too far :-]
<robclark>
dianders: ahh, ok
<robclark>
ahh, component model strikes again
<bamse>
robclark, dianders: i still think we should try to resolve all external dependencies as we probe the various components...
<bamse>
it's quite terrible that the component bind can return -EPROBE_DEFER and we of_platform_depopulate() when that happens
<robclark>
yeah, I think (now that driver core does magic things like power domains) the whole idea that we tell driver core that the driver probed while secretly it hasn't really isn't.. great..
<bamse>
we should be able to pick all those things up at probe time, so we're ready to go at bind time
<bamse>
and for the laptops that should mean that we'll still have efifb even though things probe defer
<robclark>
arnd, bamse: a bit off topic, but now that min compiler version has been bumped, can drivers start using c99/gnu99 yet?
<bamse>
robclark: any particular construct you have in mind?
<robclark>
`for (int i =0; ....)` mostly
<bamse>
i believe you can, but i'm not sure...i also would have to teach myself to accept that style again ;)
<robclark>
currently unless you override `-std=blah` you get compiler warnings about that
<robclark>
c89 is a bit annoying, mesa is all c11 so jumping back and forth is.. jarring..
<arnd>
robclark: I think we're just waiting for someone to send the patch that changes the default
<arnd>
the trouble is that it needs testing on all compiler versions
<robclark>
I have a patch which changes it.. but just in drm/msm
<dianders>
bamse: for the of_platform_depopulate() problem you're talking about the problem I hackily tried to solve in <https://lore.kernel.org/all/20210520002519.3538432-1-swboyd@chromium.org/>, right? I've actually considered that it could be also solved by using the AUX bus. That way you could have one sub-component that did the of_platform_populate() and another one that would return -EPROBE_DEFER if everything wasn't ready.
<dianders>
(and by AUX bus I don't mean DP AUX bus, but the Linux aux bus that lets you split a driver up)
<bamse>
dianders: we probably could do that, but the 2-stage process has the merit that it handles any cross-component dependencies nicely as well
<bamse>
dianders: and it would be less intrusive to just move things from bind to probe time in each component...
<steev>
bamse: i just saw the email about not taking the patch til backlight lands, but i've tested the backlight and the one you posted and they work quite nicely here
<bamse>
steev: you're saying that the backlight patch is good?
<steev>
bamse: let me back out the newer patch and triple check but i do believe yes
<bamse>
steev: just wondered which patch you referred to
<bamse>
steev: wasn't expecting anything else, but happy to hear that