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)
bryanodonoghue has joined #aarch64-laptops
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
Caterpillar has quit [Ping timeout: 480 seconds]
Caterpillar has joined #aarch64-laptops
echanude has quit [Ping timeout: 480 seconds]
<anarchron> <steev> "xnox: it's the hack we have in..." <- What hack is this? I wonder if that’s the reason why the 5G WWAN module doesn’t work because of the incorrect assignment of PCI BAR space
echanude has joined #aarch64-laptops
<steev> oooh wireless patchwork got some interesting patches
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<clover[m]> kalle stuff?
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
<xnox> steev: to be fair, i'd rather ship a fake symlink in ubuntu linux-firmware, than doing that. as that will allow me to have less delta between this x13s kernel, and generic.
init_x13s has joined #aarch64-laptops
<init_x13s> hey, ben runnning full time on the x13s for a couple day. So far so good even for that patchwork of software to make it work.
<init_x13s> only major issue I have so far is that, if i close my lid, systemd reports that the system went to suspend, but in reality, it does not.
<init_x13s> completely drains the battery then die.
<init_x13s> no error in journald
init_x13s has quit [Remote host closed the connection]
init_x13s has joined #aarch64-laptops
maspras has joined #aarch64-laptops
<maspras> hello
<ajhalaney[m]> init_x13s -- I'll admit I never suspend, but my understanding is that things like PCIe etc aren't turning off all the things they can, so right now suspend isn't super power efficient... someone more in the loop can comment on that
<init_x13s> that's what I also thought
<maspras> hello
<maspras> i maspras
<init_x13s> I'll just shutdown for now if there's no obvious solution
<maspras> hello
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #aarch64-laptops
init_x13s has quit [Remote host closed the connection]
maspras has quit [Ping timeout: 480 seconds]
<gwolf> ...The good thing is that it powers up quite quickly ;-)
<init> i'm having a good experience so far with mesa 23.0.0 on the x13s, all patches apply except MEDIA_INTERFACE_DESCRIPTOR_LOAD-reemit which does not seems to cause any issues so far.
hightower2 has quit [Ping timeout: 480 seconds]
<init> not that I had any problem wit the custom mesa from x13s-alarm, but I do hate to issue ignore package on yay updates
<HdkR> :sweats heavily:
<HdkR> Just don't run things that are too heavy :P
<ajhalaney[m]> dumb question, but is there a way to get on the freedreno IRC from matrix/element? I was hoping to become a fly on the wall there but i have failed to find it (but i do see dri-devel!)
<HdkR> It's just in #freedreno
<HdkR> Same OFTC network
<ajhalaney[m]> I was failing to find it in the search, but manually putting in (not sure why I didn't think of that far earlier) worked. Thanks HdkR
hightower2 has joined #aarch64-laptops
<init> HdkR: ? what do you mean by "too heavy"
<HdkR> init: GPU isn't fully stable yet, some games will cause GPU crashes
<steev> xnox: that won't work - we have to force a board id, since *currently* we do not exist in the board files at all
<init> ha yeah indeed, absolutely not expecting it to be near stable. i use if for office use only anyways
<steev> oh man
<steev> i just realized i've been running with screen brightness at 40%, this is a game changer at 100%
<steev> just figured my eyes were finally starting to go bad
<steev> people have been telling me since the 90s that they would from staring at the screen so long
<HdkR> I run almost all my panels at 100% brightness
<HdkR> I hate low brightness displays
<HdkR> Kind of a shame my X13s has the panel that loses 50 nits of brightness
<init> heh, I'm the weirdo who also hates any form of dark mode
<init> Give me moar light, I'm a plant after all.
Cyrinux9 has quit []
Cyrinux9 has joined #aarch64-laptops
<rfs613> steev: depends on abient light levels
<rfs613> when it's sunny, I pretty much want 100% brightness (and you may recall, I waited to order my x13s until they had the brighter screen option)
<rfs613> today is overcast, I am at maybe 60%
<rfs613> and at night when waiting for the little ones to fall asleep, i'm on minimum brightness...
iivanov_ has quit [Quit: - Chat comfortably. Anywhere.]
<bamse> steev: will not the first time someone goes blind from staring into the sun...
<steev> :D
<steev> jhovold: thank you for the reviews! i'll try to address them soon but this week is release testing week for kali, so i've not got much spare cycles
<steev> but to your questions (and i'll reply to the emails as well) - 90% of the 6855 stuff in the driver is simply based on "the 6750 does it, so the 6855 probably does too)
<steev> "
<clover[m]> wow i thought matrix was a goner. upgrading to 22.04 on my armbian server crippled python3 somehow. had to move my synapse server to a docker container, and upgrade postgres from 12 to 14
<steev> maybe it's the pip changes in python 3.11?
<clover[m]> yeah pip was all weird
<steev> just pass --break-system-packages or whatever
<steev> ez
<steev> or rename /usr/lib/python3.11/EXTERNALLY_MANAGED or whatever that file is, to... anything else
<clover[m]> this is what i get for not using arch
<steev> its a blessing and a curse, really
<steev> we backed the change out in kali, for now, but i look forward to our end users not being able to break their system and then coming to us asking why we broke it, when the backtrace clearly shows crap they installed in /usr/local
Cyrinux9 has quit []
Cyrinux9 has joined #aarch64-laptops
<clover[m]> Are you not suppose to put stuff in /usr/local ?
<HdkR> You're supposed to use the package manager for everything, if you're not they if something breaks it is entirely your fault
<HdkR> s/they/then
<steev> the issue isn't putting stuff in /usr/local, it's the user putting stuff in there and not knowing what they're doing; so the decision was made (pep688) that if users wanna pip stuff, they should do it in a virtual environment, because even doing pip --user causes it to be inserted into their path, and again, has the potential to break system level things based on newer dependencies
<amstan> the whole pip thing is such a mess
<amstan> but a lot of language package managers do it similarly
<amstan> they assume they're on windows and can just install crap everywhere, so now you have 2 package managers (pip and your distro) both trying to manage the same packages in different ways
<clover[m]> im def guilty of using pip as a secondary package manager
<amstan> i did it once, and then i realized i can't install my distro's python packages (as dependencies to other apps) anymore because they're already there
<steev> the problem i find is... a lot of users seem to just... not even bother looking at the package manager at all
<steev> they just clone $random-repo and run sudo pip install -r requirements
<amstan> steev: that's because most of those repos claim that's how you do it