01:16 <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

04:10 <steev> anarchron: https://github.com/steev/linux/commit/3233eee21e8a87ca1a87d4d3041c8ec80557a161 as an example

04:19 <steev> oooh wireless patchwork got some interesting patches

06:16 <clover[m]> kalle stuff?

09:31 <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.

14:12 <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.

14:13 <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.

14:13 <init_x13s> completely drains the battery then die.

14:13 <init_x13s> no error in journald

14:58 <maspras> hello

14:59 <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

15:01 <init_x13s> that's what I also thought

15:01 <maspras> hello

15:01 <maspras> i maspras

15:01 <init_x13s> I'll just shutdown for now if there's no obvious solution

15:02 <maspras> hello

15:47 <gwolf> ...The good thing is that it powers up quite quickly ;-)

16:48 <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.

16:49 <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

16:49 <HdkR> :sweats heavily:

16:50 <HdkR> Just don't run things that are too heavy :P

16:54 <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!)

16:55 <HdkR> It's just in #freedreno

16:55 <HdkR> Same OFTC network

17:07 <ajhalaney[m]> I was failing to find it in the search, but manually putting in #_oftc_#freedreno:matrix.org (not sure why I didn't think of that far earlier) worked. Thanks HdkR

17:55 <init> HdkR: ? what do you mean by "too heavy"

17:56 <HdkR> init: GPU isn't fully stable yet, some games will cause GPU crashes

17:56 <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

17:56 <init> ha yeah indeed, absolutely not expecting it to be near stable. i use if for office use only anyways

18:36 <steev> oh man

18:36 <steev> i just realized i've been running with screen brightness at 40%, this is a game changer at 100%

18:37 <steev> just figured my eyes were finally starting to go bad

18:37 <steev> people have been telling me since the 90s that they would from staring at the screen so long

18:48 <HdkR> I run almost all my panels at 100% brightness

18:49 <HdkR> I hate low brightness displays

18:49 <HdkR> Kind of a shame my X13s has the panel that loses 50 nits of brightness

19:03 <init> heh, I'm the weirdo who also hates any form of dark mode

19:03 <init> Give me moar light, I'm a plant after all.

19:29 <rfs613> steev: depends on abient light levels

19:31 <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)

19:31 <rfs613> today is overcast, I am at maybe 60%

19:31 <rfs613> and at night when waiting for the little ones to fall asleep, i'm on minimum brightness...

20:11 <bamse> steev: will not the first time someone goes blind from staring into the sun...

20:11 <steev> :D

20:12 <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

20:13 <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)

20:13 <steev> "

20:23 <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

20:29 <steev> maybe it's the pip changes in python 3.11?

20:31 <clover[m]> yeah pip was all weird

20:33 <steev> just pass --break-system-packages or whatever

20:33 <steev> ez

20:34 <steev> or rename /usr/lib/python3.11/EXTERNALLY_MANAGED or whatever that file is, to... anything else

20:38 <clover[m]> this is what i get for not using arch

20:42 <steev> its a blessing and a curse, really

20:43 <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

22:30 <clover[m]> Are you not suppose to put stuff in /usr/local ?

22:37 <HdkR> You're supposed to use the package manager for everything, if you're not they if something breaks it is entirely your fault

22:38 <HdkR> s/they/then

22:51 <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

23:30 <amstan> the whole pip thing is such a mess

23:31 <amstan> but a lot of language package managers do it similarly

23:31 <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

23:31 <clover[m]> im def guilty of using pip as a secondary package manager

23:32 <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

23:54 <steev> the problem i find is... a lot of users seem to just... not even bother looking at the package manager at all

23:54 <steev> they just clone $random-repo and run sudo pip install -r requirements

23:59 <amstan> steev: that's because most of those repos claim that's how you do it