xmn has quit [Read error: Connection reset by peer]
xmn has joined #maemo-leste
xmn has quit [Ping timeout: 260 seconds]
<Wizzup> sicelo: on upower, shall I just build the one from trixie (if that is new enough) for daedalus?
xmn has joined #maemo-leste
Daanct12 has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
<sicelo> Trixie version is fine. although if there are no other concerns, I think git master is preferable
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
joerg has quit [Ping timeout: 260 seconds]
System_Error has quit [Remote host closed the connection]
joerg has joined #maemo-leste
System_Error has joined #maemo-leste
_fab has joined #maemo-leste
<freemangordon> Wizzup: we use cgroups v2, right?
<freemangordon> arno11: instead of doing sudo, perhaps you can check what cgrulesengd can do for us (in cgroups v2 you can assign nice value to a group)
<freemangordon> so we can distribute /etc/cgrules.conf with rules for Xorg, mce, h-d, etc
<freemangordon> and we can use ohm rules from fremantle
<freemangordon> s/use/port
<freemangordon> hmm, at least VM is using cgroup v1
<freemangordon> arno11: see /usr/share/policy/etc/current/syspart.conf
<freemangordon> I am really tempted to consider moving to systemd, we get all those things there with unit files
<freemangordon> anyway...
<freemangordon> arno11: seems we can use inotify to watch new processes creation
<freemangordon> 'processed': https://paste.debian.net/1364526/
<freemangordon> everything else is done through cgroups
<freemangordon> for Xorg, we should be able to set nice value from the startup script
<freemangordon> hmm, we do it, but autologin starts new pam session, which starts Xorg with nice 0
<freemangordon> so, we shall create some daemon/script/whatever that monitors processes creation and sets the appropriate nice value
_fab has quit [Quit: _fab]
xes has quit [Ping timeout: 268 seconds]
xes has joined #maemo-leste
<Wizzup> no, let's not make a new daemon
<Wizzup> let's do it this way
<Wizzup> for xsession scripts, we can use cgrun if we must hack it in there
<Wizzup> and ifwe do have cgrulesengd, why do we need another daemon?
pere has quit [Ping timeout: 246 seconds]
pere has joined #maemo-leste
pere has quit [Ping timeout: 246 seconds]
mkf has joined #maemo-leste
<mkf> hello.
<mkf> i've got otg working today. :)
<sicelo> nice progress! what image is your work based on btw?
<mkf> sunxi image in the website, but it's quite change right now.
<mkf> *changed
<mkf> also updated to chimaera
<mkf> have wireless worked for you? i'm not sure if i'm doing something wrong or i have fired the chip... :(
<mkf> freemangordon, Wizzup: ^
xmn has quit [Quit: Leaving]
pere has joined #maemo-leste
DFP has quit [Quit: Leaving]
Kabouik has quit [Remote host closed the connection]
<freemangordon> mkf: wifi works on my sunxi, but I had to patch the driver
<freemangordon> my tablet has some exotic realtek chip
<freemangordon> Wizzup: cgrulesengd can't control nice value
<freemangordon> or rather - we use cgroups v1, which can't control niceness
<freemangordon> if we can enable cgroup v2, then we don;t need another daemon
<freemangordon> hmm...
<freemangordon> oh, wait, seems v2 is mounted under /sys/fs/cgroup/unified
<freemangordon> so yeah, we can go with v3
<freemangordon> *v2
<Wizzup> freemangordon: then we rename in the xsession
<Wizzup> renice*
<freemangordon> no, we can't
<freemangordon> xsession is run as user
<Wizzup> why not? sudo renice $(pidof Xorg)
<freemangordon> no, wait
<Wizzup> looks like pam can let users set negative niceness
<freemangordon> but we want to ue cgroups for that
<freemangordon> *use
<Wizzup> ok, if cgroups v2 can do it
<freemangordon> yes, they can
<freemangordon> they have the so called 'sched' controller
<freemangordon> that seems to support niceness
<freemangordon> at least AI said so :)
<mkf> freemangordon: mine has that too. :)
<mkf> what patches you made?
<Wizzup> freemangordon: I am not sure if I will believe AI, but ok
<freemangordon> "echo 10 > /sys/fs/cgroup/my_cgroup/sched.niceness"
<freemangordon> mkf: what exactly?
<Wizzup> freemangordon: ok, well, let me fix this n900 fstab issue first, but it sounds like cgroups is the answer here
<freemangordon> mhm
<Wizzup> freemangordon: btw, any chance to look at git.maemo.org? if we're happy with it I might do the migration some time soon
<Wizzup> or at least proceed further with the migration
<Wizzup> I'll check out some sign in via github kind of things, too
<freemangordon> sorry, but I lost the context why do we need to migrate out of github
<freemangordon> iow, what is wrong with github?
<Wizzup> it's closed source, it's microsoft, it's US based, the CI/CD is not our own, and I don't want to say build packages on github infra
<Wizzup> and I don't trust them to not throw us off when anyone complains
<freemangordon> ok :)
<freemangordon> oh, so we can do builds on commit with our infra?
<Wizzup> the reason we went for it initially was that we thought the network effect would attract people
<Wizzup> re: builds on commit - I plan to make that work, yes
<freemangordon> ok, cool
<freemangordon> ok, will have a look soon
<mkf> freemangordon: rtl8723bs or 8702as or something like that...
<freemangordon> no, it is important the *exact* chip
<freemangordon> because if it is BS, it is the same as mine and I would be able to help
<mkf> how do i know what's the chip exactly?
<freemangordon> check in fex
<mkf> ok
<freemangordon> mkf: all the changes I have made https://paste.debian.net/1364571/
<freemangordon> at the end is drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
<freemangordon> BTW, your issues with TS might be related with wrong panel config
<freemangordon> see unk_qc760bg1_1024_600_72_mode
<freemangordon> bbl
<mkf> mine is 800 x 480 tho
<freemangordon> how do you know? from fex?
<mkf> fex.
<freemangordon> ok
<mkf> however the image isn't the original one shiped with device, and wifi doesn't work in android, so i'm not sure if fex is to be trusted about wifi
<mkf> sunxi wiki says i should have a realtek, and i do see a realtek chip in my board
<freemangordon> ok
<mkf> but fex (of incompatible?) android image says i have an rda. which i don't think is true.
<freemangordon> did you enable the driver?
<freemangordon> it is in staging
<mkf> i have, but didn't applied the patches yet
<mkf> let me recompile
<freemangordon> wait
<freemangordon> did it probe properly?
<freemangordon> *does it*
<mkf> how do i know?
<freemangordon> lsmod?
<mkf> it loads it fine (added it in /etc/modules)
<freemangordon> you should not load it by hand
<mkf> oh. ok.
<freemangordon> lemme boot my device to be sure what happens
<mkf> if i don't load it, who will load it then?
<freemangordon> umm... who loads the other modules?
<freemangordon> udev I would say
<mkf> idk, i load all modules by hand. :)
<freemangordon> oh, how's that?
<mkf> gotcha.
<mkf> idk, silead didnt worked properly and i thought modules must be manually loaded.
<freemangordon> nope
<freemangordon> everything here is auto-probed
<freemangordon> keep in mind that even with that patch wifi has issues connecting every now and then
<mkf> oh well.
<freemangordon> [ 13.172909] r8723bs: module is from the staging directory, the quality is unknown, you have been warned.
<mkf> it's not laoded automatically.
<mkf> *laoded
<mkf> silead did, so i think it's not probed.
<mkf> or my dts is faulty. hm.
<freemangordon> yeah, could be
<freemangordon> what dts do you use? sun8i-a33-q8-tablet.dts ?
<mkf> a23-q8-tablet
<freemangordon> oh, yours is not a33
<mkf> yeah but these two are close enough.
<freemangordon> rtl8723bs: sdio_wifi@1 {
<freemangordon> so yeah, same chip
<mkf> (i have modified this file)
<mkf> original file
<freemangordon> there is nothing about wifi there
<mkf> yeah. :(
<freemangordon> hmm, wait
<freemangordon> &mmc1
<freemangordon> it is missing "status = "okay"; ,no?
<mkf> sun8i-q8-common.dtsi does define &mmc1
<mkf> and it has status ok
<freemangordon> ok
<mkf> tho it doesn't mention what wifi model it has
<freemangordon> (I have kernel trees here, no need to paste upnaptched files)
<freemangordon> *unpatched
<mkf> sorry, i'm not very fluent in device tree tounge. :)
<mkf> okay. thanks.
* freemangordon checks
<mkf> opened the tablet, apperently it has a 87?3As
<freemangordon> so not BS?
<mkf> no.
<freemangordon> well,...
<mkf> but these two share the same driver
<freemangordon> that explains it
<freemangordon> do they?
<freemangordon> ok, but are you sure it is on emmc bus?
<mkf> at least here says they share the same driver
<freemangordon> yeah
<mkf> i'm not sure if they are on emmc bus tho.
<freemangordon> "SDIO"
<mkf> ah.
<mkf> wait emmc is too sdio? huh.
<mkf> i thought they are distant standards
<mkf> okay that explains a bit why a wifi should be on emmc
apac has joined #maemo-leste
<freemangordon> mkf: do you have anything "sdio" in dmesg?
<freemangordon> also, check /dev/bus/sdio
<gnarface> i have the same SDIO unit on a 2GB pine64+ board, and the debian kernel didn't have the right dtb patch, i had to manually add it
<gnarface> device was showing up unpowered
<gnarface> same driver too, lemme know if you can get more than 20 megabits out of it in host mode
<gnarface> it'll work but i can't make it as fast as it's supposed to be (150MB/s!?)
<freemangordon> gnarface: see https://paste.debian.net/1364571/, I think there is a bug in the driver
<freemangordon> (patch at the end)
<freemangordon> without that it does not even connect to my router here :)
<freemangordon> or does it once in 20 reboots ;)
<gnarface> hmm
<gnarface> interesting...
<mkf> gnarface, thank you. i think i never seen a n card go beyond 10Mb (18 Mb is theorical limit of 150MB cards)
<gnarface> freemangordon: you mean just this hunk for drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c? you think that'll fix the speed issue?
<gnarface> or do i need more of this?
<freemangordon> no idea
<gnarface> hmmm
<freemangordon> but at least it allows me to connect to my router 9 of 10 times
<freemangordon> gnarface: btw, what do you use to test speed?
<gnarface> seems promising...
<gnarface> usually testing with netcat
<gnarface> just time and netcat of a cached 50mb file from a ram disk to /dev/null
<gnarface> 50MB i mean
<freemangordon> yeah
<mkf> gnarface: megabit or megabyte?
<gnarface> heard some accounts of 60 megabits with wpasupplicant but they hadn't tested in host mode, so there also might be a speed discrepancy between host mode and client mode
<gnarface> mkf: MB == megabyte, mb == megabit
<freemangordon> lemme see if I'll be able to run speedtest.net :)
<mkf> aren't cards rated for mb?
<gnarface> yes, but the SDIO bus is rated in MB, i thought...
<mkf> hm.
<gnarface> basically it's supposed to be good for 150MB/s, current kernel/dtb settings show it should at least be working at 40MB/s, but the best first-hand accounts i've heard can't get more than 6MB/s out of it and in host mode i can't get more than 2MB/s out of it
<freemangordon> ok, according to speedtest.net, my DL speed is 39.54, my UL is 46.78
<gnarface> MB or mb?
<freemangordon> Mbps
<gnarface> hmm, still basically double what i'm getting
<gnarface> so maybe that patch is helping
<freemangordon> those speeds are pretty normal, as my inet is 100Mb or something
<freemangordon> and also, chromium uses some CPU, so that affects speets too I would say
<freemangordon> *speeds
<freemangordon> lemme re-test
arno11 has joined #maemo-leste
<freemangordon> 20.57/53.09
<freemangordon> but web page trying to show speed meter in real-time does not help much
<arno11> freemangordon: Wizzup: great @cgroup
<mkf> freemangordon: are you running chromium on a33?
<freemangordon> yes
<mkf> does that work well?
<mkf> (is it jib?)
<freemangordon> no, *chromium*
<mkf> oh.
<freemangordon> works ok
<mkf> i see.
<freemangordon> with ublock origin, it is 'ok'
<mkf> wait a sec
<freemangordon> gnarface: so, with speedtest page scrolled so meter is hidden, I get 45.11/63.96
<freemangordon> mkf: hmm?
<gnarface> freemangordon: that's in client mode though, it'd be interesting to see if it can maintain those speeds in host mode
<freemangordon> no idea, I admit I have never used host mode :)
<gnarface> that is more like what i've heard other people say they were getting out of it in client mode though
<mkf> kernel nags about lack of regulatory db for 802.11
<mkf> could that might be a reason?
<freemangordon> yeah, we knbow
<freemangordon> no
<gnarface> doesn't installing the crda package get rid of that error?
<mkf> hm ok
<freemangordon> gnarface: no, because we build our kernels
<gnarface> oh
<freemangordon> and there is something with the keys
<mkf> i built my own, does it effects that?
<freemangordon> kernel?
<mkf> yeah.
<freemangordon> sure
<mkf> i have another wifi card, that's usb
<mkf> and apperently it gets detected enough so ip a can see it
<mkf> tho idk how to connect to wifi in maemo thru terminal (gui doesn't show a thing)
<mkf> do we use iwl in maemo?
<freemangordon> use wpa_supplicant
<freemangordon> or rename to wlan0
<freemangordon> then maemo will see it
<freemangordon> Wizzup: ok, won't work with cpu.weight.nice
<freemangordon> this does not change niceness, but some scheduling priority within the group
<Wizzup> we can leverage pam to allow user to set negative nice with renice
<Wizzup> or maybe scheduling priority is enough
<freemangordon> otoh, do we want to enable non-root to set niceness < 0?
<freemangordon> I don't like the idea
<freemangordon> I'd better invent some more secure way
<freemangordon> or really, just create a 20-liner script (part of leste-config) that does inotifywait on /proc
<Wizzup> it all feels like bad hacks imo
<Wizzup> strange that we can't just put nice -20 in front of something.
<freemangordon> if you allow user to do that, a user-started runaway process will hang the system
Daanct12 has quit [Quit: WeeChat 4.5.2]
<freemangordon> so I don't think that's a good idea
<freemangordon> bbl
Daanct12 has joined #maemo-leste
Daanct12 has quit [Client Quit]
arno11 has quit [Quit: leaving]
pere has quit [Ping timeout: 268 seconds]
akossh has joined #maemo-leste
mkfx has left #maemo-leste [#maemo-leste]
parazyd has quit [Ping timeout: 252 seconds]
parazyd has joined #maemo-leste
parazyd has quit [Changing host]
parazyd has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11> Wizzup: freemangordon: maybe an alternative: i created a basic bash script (root) with the needed renice commands, linked to a xsession.post file (99my_script) and surprisingly works fine
<Wizzup> I'm not surprise it works
<Wizzup> we're just trying to figure out a way not to leverage passwordless sudo on user to work around this
<Wizzup> as in, make it a bit more future proof, so to say
<arno11> yeah ofc
pere has joined #maemo-leste
_fab has joined #maemo-leste
_fab has quit [Quit: _fab]
_fab has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
_fab_ has joined #maemo-leste
_fab has quit [Ping timeout: 252 seconds]
_fab_ has quit [Ping timeout: 252 seconds]
mkfx has joined #maemo-leste
<mkf> yipeee \o/
<mkf> wifi now probes
<freemangordon> mkf: how?
<mkf> i'm a dummy, it turns out i've compiled the incorrect driver.
<freemangordon> heh
<mkf> it loads this one now, and it's detected as wlan0
<mkf> alas maemo still shows no wifi networks
Twig has joined #maemo-leste
<Wizzup> maybe you need to restart icd2
<mkf> uh. how can i stop hildon from starting?
<mkf> or xorg even.
<freemangordon> move dsme out of /etc/init.d/
<mkf> okay.
<mkf> now got wifi in maemo working, altough i can't connect. trying to apply your patch..., which version of kernel this patch is for?
<freemangordon> 6.12?
<mkf> oh.
<mkf> i suppose that driver got quite some love in versions between 5.8 and 6.12.
<mkf> hm, linux 5.8 already have done what you did roughly.
<mkf> nvm.
tk has quit [Remote host closed the connection]
tk has joined #maemo-leste
xmn has joined #maemo-leste
ashley has quit [Quit: Whatever.]
arno11 has joined #maemo-leste
<freemangordon> mkf: better use at least 6.12
<freemangordon> it works fine, at least here on a33
Livio has joined #maemo-leste
xmn_ has joined #maemo-leste
<arno11> freemangordon: btw any idea about what's going on with Qt5 apps launch time ?
xmn has quit [Ping timeout: 276 seconds]
<arno11> gpu related or ?
<arno11> it is even a lot slower if i try to open more than one qt app.
<arno11> if i use rasterisation (force raster surface in qt5ct), it is almost as fast as what you described for d4. and i can open 4 or 5 qt apps @the same time with no troubles
<arno11> (i.e calculator, qalendar, hamsterfiler, conversations, tg-desktop)
<arno11> impossible OOTB with daedalus
xmn has joined #maemo-leste
xmn_ has quit [Ping timeout: 276 seconds]
<mkf> freemangordon: will do after i got mali up :)
Kabouik has joined #maemo-leste
Kabouik has joined #maemo-leste
Kabouik has quit [Changing host]
<mkf> hm. strange, mali is apperently loaded but there is no /dev/dri/dri0
Kabouik has quit [Remote host closed the connection]
Livio has quit [Ping timeout: 264 seconds]
Twig has quit [Remote host closed the connection]
<Wizzup> mkf: why mali and not lima
<mkf> yeah i meant lima
<mkf> it seems /dev/dri/card0 is there but for some reason X can't open it (no such file or directory)
<mkf> it even exists before X runs
<sicelo> user permissions perhaps?
<mkf> might be, but chown'd em to be sure and nothing changed
<mkf> i've also ran X as root for test, and it can access /dev/dri/card0, but glxinfo still tells me i'm using llvmpipe
mkfx has left #maemo-leste [#maemo-leste]
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup> sicelo: re: upower, trixie is easier, but we can also do master
akossh has quit [Quit: Leaving.]
<sicelo> sure, should be OK
<sicelo> FYI, I currently have a build of upower that reports the following, https://paste.debian.net/1364641/ .... << freemangordon ;-)
xmn has quit [Quit: Leaving]
lyubov has quit [Read error: Connection reset by peer]
<sicelo> maybe upower folk won't like the direct exporting of the capacity_level string, and prefer some kind of enum. anyway, i'll clean this up tomorrow, and open an MR for their review
lyubov has joined #maemo-leste
<Wizzup> cool :)
xmn has joined #maemo-leste