* inky got mz617 in summer in hope to use it with maemo. it lives in a drawer waiting for better times.
ac_laptop has quit [Quit: WeeChat 3.8]
xmn has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
System_Error has quit [Ping timeout: 264 seconds]
mkfx has joined #maemo-leste
System_Error has joined #maemo-leste
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
joerg has quit [Killed (tantalum.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
narodnik has joined #maemo-leste
System_Error has joined #maemo-leste
narodnik has quit [Quit: WeeChat 4.5.1]
narodnik has joined #maemo-leste
<Wizzup> ~
<freemangordon> hmm?
<Wizzup> inky: OBlag :)
<Wizzup> freemangordon: lag
<Wizzup> lol
<freemangordon> heh
<Wizzup> inky: soon enough
<Wizzup> I am using mz617 now with qalendar and apart from qalendar sometimes crashing it's quite nice!
<Wizzup> fun to type notes and tasks using the vkb only in qt
narodnik has quit [Quit: WeeChat 4.5.1]
narodnik has joined #maemo-leste
<freemangordon> Wizzup: hmm, not sure what to do
<freemangordon> seems xorg has issues with drm devices order
<Wizzup> freemangordon: this being multiple 'video cards' in drm or something?
narodnik has quit [Quit: WeeChat 4.5.1]
narodnik has joined #maemo-leste
narodnik has quit [Quit: WeeChat 4.5.1]
narodnik has joined #maemo-leste
xmn has quit [Quit: Leaving]
<freemangordon> yes
<freemangordon> like we have on omap
<freemangordon> for example modesetting will use card0 by default, despite it is for SGX
<freemangordon> I am just moaning, not that we can do anything about that
<freemangordon> I'll just fix omap driver to return false from Probe function if there is platform probe support in xorg
<freemangordon> not sure that's the proper way, but meh
_fab has joined #maemo-leste
xes has quit [Ping timeout: 272 seconds]
mkfx has left #maemo-leste [#maemo-leste]
xes has joined #maemo-leste
akossh has joined #maemo-leste
<Wizzup> freemangordon: we might be able to set te card in xorg.conf
<Wizzup> if they are predictable (usually no0t
Pali has joined #maemo-leste
<freemangordon> Wizzup: no, I just disable driver probe if platform probe is supported
<freemangordon> (whatever those are :) )
DPA has quit [Ping timeout: 272 seconds]
<freemangordon> Wizzup: ok, got it working with daedalus Xorg, will take a rest and will push the changes
<freemangordon> btw, do we have fulscreen QT application to test with, if it still crashes SGX?
Anasko has joined #maemo-leste
<Wizzup> freemangordon: I think we can add that to jib
<Wizzup> (again)
<Wizzup> freemangordon: great!
<freemangordon> Wizzup: well, but I want to test before we put anythong in the repo
<freemangordon> *anything
<freemangordon> maybe smplayer
<Wizzup> mpv?
<Wizzup> freemangordon: ok, but nobody uses repo yet
<Wizzup> :)
<Wizzup> it is just us
<Wizzup> and only you have a d4 img
<freemangordon> ok, if you can do it
<freemangordon> fort jib that is
<freemangordon> *for
<freemangordon> anyway, bbl
DPA has joined #maemo-leste
<dsc_> yes jib crashed previously
<dsc_> @fullscreen
<Wizzup> freemangordon: sure, when you push the changes I will test :D
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
Anasko has quit [Ping timeout: 244 seconds]
arno11 has joined #maemo-leste
<arno11> note that it is not affecting only qt apparently, pcsx rearmed crashes in fullscreen with opengles rendering too
<arno11> works perfectly fine in window mode even with scale x2
arno11 has left #maemo-leste [#maemo-leste]
Twig has joined #maemo-leste
mkfx has joined #maemo-leste
<freemangordon> Wizzup: BTW, we have to change xorg service because of the changed log fule location
<freemangordon> *file
<freemangordon> Wizzup: ok, with xorg/ddx from repos d4 boots to h-d
<freemangordon> hmm, and it crashed :(
<freemangordon> hmm, maybe low battery
halftux has joined #maemo-leste
<freemangordon> no, it really crashes
<freemangordon> what the?
<freemangordon> hmm, maybe mce shuts-down because battery is not calibarated
<freemangordon> yeah, ok, does not reset with charger connected
<sicelo> :-)
<sicelo> stock upower?
<freemangordon> yes
<freemangordon> hmm, wait
<freemangordon> I remember we changed the config
<freemangordon> sicelo: do you know where config is?
<sicelo> while you debug, i'm interested in your `/sys/class/power_supply/...battery/uevent`
<sicelo> freemangordon: config for?
<freemangordon> upower
<freemangordon> or, was it for logind?
<sicelo> /etc/UPower.conf ... but UPower doesn't really have much options there
<freemangordon> sicelo: uevent is from 6.6, what do you expect to see?
<freemangordon> Linux devuan-droid4 6.6.53 #1 SMP PREEMPT Sat Nov 30 17:40:52 UTC 2024 armv7l GNU/Linux
<sicelo> just what an uncalibrated uevent looks like. want to keep it for my notes, and perhaps future upower work
<freemangordon> ah, ok
<freemangordon> I guess I will have to stop upower, roght?
<sicelo> i can get it from my D4 as well though, later on
<freemangordon> hmm, seems I cannot stop it
<freemangordon> sicelo: https://pastebin.com/xzUSnxiJ
<freemangordon> charger/no charger
<freemangordon> I wonder why upower ignores POWER_SUPPLY_CAPACITY_LEVEL=High
<sicelo> when upower decides that shutdown should happen, it sends a request to logind for that. so a quick hack would be to request a shutdown inhibit lock through logind
<freemangordon> but we alredy do
<freemangordon> *already
<freemangordon> or, I thought so
<sicelo> freemangordon: they say CAPACITY_LEVEL only matters for peripherals (they're wrong, and wouldn't budge)
<freemangordon> bbiab
<sicelo> but, upower maintainership seems to have changed since then, so we could have a go at this conversation with them
halftux_ has joined #maemo-leste
halftux has quit [Ping timeout: 252 seconds]
<Wizzup> we shouldhave logind ignore all of this
<Wizzup> the key names changed perhaps
<freemangordon> Wizzup: seems not
<freemangordon> bbl, dinner
<Wizzup> they changed on my gentoo laptop recently
<Wizzup> ttyl
<sicelo> i'm also not in a position to check atm, but under normal circumstances (upower aside), i think we do want logind to respond to shutdown requests. e.g. users should be able to `loginctl shutdown` (which is basically the same request upower makes). leste currently works fine with this
<sicelo> what i would need to confirm is - who actually makes the request to shut down the system (Leste) atm - is it MCE, after receiving appropriate signal from upower, or the shutdown request goes directly from upower to logind
<sicelo> most stacks simply let logind (and upower) handle this stuff on their own. in our case, afaiui, we want mce to control system shutdown, etc., so it would seem mce needs to start holding inhibitor lock against shutdown operation
<sicelo> i think mce qualifies for the 'blocking' lock type in that documentation
<freemangordon> sicelo: mce asks dsme which asks logind :D
<freemangordon> it is not that simple
<freemangordon> it is not only mce that can request shutdwon
<freemangordon> (iirc)
<sicelo> besides the user, who else can request it?
<sicelo> anyhow, since upower 1.90.5 (https://gitlab.freedesktop.org/upower/upower/-/releases/v1.90.5), upower can be told to do nothing when it thinks shutdown is needed. maybe this would suit our needs
<sicelo> i use that config under pmos with an udev rule that initiates shutdown when kernel sends uevent to say CAPACITY_LEVEL = Low/Critical, thus completely bypassing upower for making shutdown decisions
<freemangordon> cool
<freemangordon> hmm
<freemangordon> upower 0.99.20-2
<freemangordon> won't fly
<freemangordon> maybe we shal jump to upstream upoerw anyways
<sicelo> what glib2 is in daedalus? this upower needs at least 2.66
<freemangordon> libglib2.0-0:armhf 2.74.6-2+deb12u5
<sicelo> seems like this would be best option then :-)
<freemangordon> hmm, latest is Released: 2025-01-09
<freemangordon> lemme pull it
<halftux_> Wizzup: My rpi3 was broken got in early stage ovserial console PMIC: timeout reading reg 00 (error -1)
<freemangordon> sicelo: ok, upstream upower is entangled with systemd :(
<freemangordon> I wonder if we shouldn't move to systemd
narodnik2 has quit [Quit: WeeChat 4.5.1]
<sicelo> no, you can run it just fine without systemd. just need the correct ./configure options
narodnik2 has joined #maemo-leste
<freemangordon> ok, but won;t' do it now
<sicelo> haven't compiled it in a while, but iirc something like `-D systemdunitdir=/no`
<sicelo> it
<sicelo> it's "-Dsystemdsystemunitdir=no"
<freemangordon> ok, lemme check
<freemangordon> in the meanwhile chromium crashes :(
<freemangordon> sicelo: ok, upgraded upower, lets see if system wil boot at all :)
<freemangordon> ok, still boots
<freemangordon> not now
<freemangordon> :)
<sicelo> then upower will never try to shutdown the system. obviously, that needs the shutting down decision to move somewhere else. i went with udev, but we can do it in mce perhaps
<sicelo> sure, no rush :-)
Anasko has joined #maemo-leste
<freemangordon> ugh, will have to build mesa on device :(
<sicelo> i wonder how long that'd take on N900 ... a week? :-D
<Wizzup> freemangordon: why not on the armhf vm?
<freemangordon> I'll directly build in ci
<freemangordon> the bug is abvious
<freemangordon> *obvious
<Wizzup> ok
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Livio has joined #maemo-leste
arno11 has joined #maemo-leste
<freemangordon> Wizzup: BTW, we will have to set DPI
<freemangordon> RN everything is tiny on d4 :)
<Wizzup> that's new
halftux_ has quit [Quit: leaving]
<freemangordon> I think we were doing something about DPI?
<Wizzup> don't remember, now in leste-config I don't think
<Wizzup> X just reads dpi from screen
<Wizzup> leste-config-common/etc/profile.d/gtk-maemo.sh.leste:export GDK_DPI_SCALE=1.7
<Wizzup> there is this but I think this is gtk3
<Wizzup> freemangordon: should I build a new img, or do you want me to wait?
<freemangordon> I think you can
<freemangordon> ugh:
<freemangordon> dimensions: 960x540 pixels (203x114 millimeters)
<freemangordon> hmm, wait
<freemangordon> what should be the dpi?
<freemangordon> dimensions: 960x540 pixels (254x142 millimeters)
<freemangordon> 254x142, eh?
<Wizzup> that is the screen size
<freemangordon> the real dpi is 270, IIUC
<freemangordon> not 96
<Wizzup> 270 sounds about right
<Wizzup> on chimaera X says DPI set to (96, 96)
<Wizzup> nothing in xrdb
<freemangordon> yes, but here it seems dpi is taken into account
<Wizzup> by who? gtk? h-d?
<freemangordon> xorg
<freemangordon> *everything* is tiny
<Wizzup> looks like xorg changes more than we think :)
<Wizzup> 254mm = 2.5cm - that seems wrong, no?
<Wizzup> wait, 25cm
<Wizzup> that's also wron
<freemangordon> yes, it is
<freemangordon> but that's reported by xdpyinfo
<Wizzup> it this in dts?
<Wizzup> is this*
<freemangordon> that means dpi 96
<freemangordon> I think it is nowhere
<freemangordon> and xorg assumes dpi of 96 by default
<freemangordon> and then simply multiplies the resolution
<freemangordon> a wild guess
<Wizzup> you can set it with xrandr --dpi I think
<freemangordon> no efffect
<Wizzup> or when starting X, or in config, or setting in dts I guess
<freemangordon> config?
<Wizzup> xorg.conf
<freemangordon> ok, but how?
<freemangordon> hmm
<Wizzup> By default, Xorg always sets DPI to 96 since 2009-01-30. A change was made with version 21.1 to provide proper DPI auto-detection, but reverted.
<Wizzup> you will have to restart programs after changing dpi with xrandr
<freemangordon> ok, lemme try
<Wizzup> but, with a monitor section you can set real display size
<Wizzup> in xorg.conf.d
<freemangordon> does not help much
<freemangordon> only fonts in launcher are increased
<Wizzup> after restarting X?
<freemangordon> yeah, fonts are huge now
<freemangordon> yes
<Wizzup> with monitor in xorg.conf.d?
<Wizzup> what about xrdb -query | grep -i dpi
<freemangordon> h-d icon sizes are the same
<freemangordon> I need microscope for chromium, no matter what I do :)
<freemangordon> ok, lemme compare with chimaera
<Wizzup> what is it in daedalus?
<Wizzup> what did you write in xorg.conf.d?
<freemangordon> ok, h-d is ok
<freemangordon> h-d in daedalus and chimaera look the same
Twig has quit [Remote host closed the connection]
<freemangordon> but, chromium at least is tiny
<freemangordon> GDK_DPI_SCALE seems to be ignored
<freemangordon> --force-device-scale-factor works
<freemangordon> Wizzup: is it possible that I am just missing gtk3 themes?
<freemangordon> ok, the same issue in the VM
<freemangordon> so not D4 related
<Wizzup> well is anything you are using gtk3?
<freemangordon> chromium is
<freemangordon> more or less
<Wizzup> ok, so ignoring chromium, what else is
<freemangordon> nothing I guess
<Wizzup> I'm still not clear what qrdb prints for you, or what xorg.conf.d you set
<Wizzup> xrdb
<freemangordon> but, GDK_SCALE=2 works with chromium
<Wizzup> well, if it's just chromium, maybe we can live with that for today
<Wizzup> leste-config-common/etc/profile.d/gtk-maemo.sh.leste:export GDK_DPI_SCALE=1.7
<freemangordon> xrdb -query
<freemangordon> *customization:-color
<Wizzup> is this not present for you?
<freemangordon> it is
<freemangordon> but is ignored
<Wizzup> ok
<freemangordon> GDK_SCALE works
<Wizzup> I see
<Wizzup> and this is X app,not some wayland stuff right?
<freemangordon> yes
<Wizzup> ok
<freemangordon> oh, wait
<freemangordon> lemme test something
<Wizzup> but other than this, if I build an image now, will h-d and icons and osso-xterm look ok?
<freemangordon> yes
<Wizzup> ok
<Wizzup> I will do that tomorrow then
<freemangordon> ok
<Wizzup> I got up at 4am so it's bed time for me :)
<freemangordon> ugh
<freemangordon> night!
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
akossh has quit [Quit: Leaving.]
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Livio has quit [Remote host closed the connection]
Livio has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
Pali has quit [Quit: Pali]
<inky> > they changed on my gentoo laptop recently
<inky> >
<inky> > ttyl
<inky> wow fellow gentoo folk. (:
xmn has joined #maemo-leste
<gnarface> afaik 96dpi is hardcoded default; no auto-detection took place
<gnarface> (i've had to set it manually for some time now, but i don't know if it's always been wrong or it's just recently that my available displays have had extreme enough native dpi to notice a problem)
<gnarface> basically for years i just happened to be using a 96dpi display
<gnarface> then more recently i got my hands on a couple pine64 devices with really super high dpi, and a projector with a really super low dpi, and that's when it became apparent no auto-detection was taking place and i would have to specify it manually
<gnarface> but it's possible that sometime before that it was also off but i just didn't notice because my older display's native dpi at the time wasn't that far off the default 96dpi value
<gnarface> ...but when your display is pushing 300dpi you're gonna have issues rendering fonts right in gtk
<gnarface> (i think some of this complication may have also stemmed from changes to fontconfig)
Livio has quit [Quit: leaving]