pere has joined #maemo-leste
uvos__ has quit [Ping timeout: 276 seconds]
maemish_ has joined #maemo-leste
nmdv has joined #maemo-leste
nmdv has quit [Ping timeout: 255 seconds]
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #maemo-leste
nmdv has joined #maemo-leste
Danct12 has joined #maemo-leste
maemish_ has quit [Quit: Connection closed for inactivity]
nmdv has quit [Ping timeout: 255 seconds]
xmn has quit [Ping timeout: 268 seconds]
maemish_ has joined #maemo-leste
macros_ has quit [Ping timeout: 256 seconds]
macros_ has joined #maemo-leste
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
Twig has joined #maemo-leste
ceene has joined #maemo-leste
maemish_ has quit [Quit: Connection closed for inactivity]
rafael2k has joined #maemo-leste
Twig has quit [Remote host closed the connection]
pere has quit [Ping timeout: 265 seconds]
M1peter10[m] has quit [Quit: You have been kicked for being idle]
pere has joined #maemo-leste
uvos__ has joined #maemo-leste
k1r1t0 has joined #maemo-leste
Danct12 has quit [Quit: WeeChat 3.8]
xmn has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11> freemangordon: the 4 pkg update from yesterday evening increase power consumption of 50mA
<arno11> I've triple checked and tested from fresh install twice
<arno11> otherwise idle is now 47mA with overclock :)
<arno11> and without the 4 pkg
<arno11> no more poweroff issue when disabling probs modules
<arno11> back in 2 hours
arno11 has left #maemo-leste [#maemo-leste]
<freemangordon> hmm, I saw similar on d4
<freemangordon> (increased power usage)
<freemangordon> will try to downgrade Xorg
<Wizzup> maybe noise on dbus?
<Wizzup> not sure how xorg can cause it
<freemangordon> but why?
<freemangordon> see https://pastebin.com/9xzCQxbL
<Wizzup> maybe X has access to more/less and does more/less? no idea...
<Wizzup> maybe compare X logs or something
<Wizzup> or maybe still some profile sourcing thing
<Wizzup> (not sure)
<freemangordon> profile is sourced correctly
<freemangordon> will try to start xorg as root
<freemangordon> to see if it will make any difference
<sicelo> 47mA? wow!
<sicelo> sounds news-post-worthy ... tmo people would love to hear such news. may generate a bit more interest in Leste too
<Wizzup> it is, but it is not yet in any leste-config pkg
<Wizzup> :)
<freemangordon> Wizzup: confirmed, it is xorg running as user :(
<Wizzup> huh
<Wizzup> maybe check if xorg has additional fds open or something
<Wizzup> or maybe check if their env is different
<Wizzup> I feel like this might be some pvr option not being read
<Wizzup> maybe pvr xorg cannot read /etc/powervr etc
<freemangordon> it is empty
<freemangordon> and I would expect errors in the log
<Wizzup> maybe strace?
<freemangordon> of Xorg?!?
<Wizzup> sure
<Wizzup> why not?
<freemangordon> who will read that?
<freemangordon> not me
* freemangordon hides :)
<Wizzup> I don't think it does a lot when screen is off
<Wizzup> but maybe I am wrong
<freemangordon> hmm
<freemangordon> I'd rather attach gdb
<Wizzup> for me, on my d4, currently, only upower takes about 8% cpu
<Wizzup> and udev 5%
<Wizzup> but that's probably just the usual full battery charging noise
<freemangordon> is it on charger?
<Wizzup> it was, yes
<Wizzup> so I checked, Xorg does nothing with screen off
<freemangordon> well, with Xorg running as root, avg current should be about 50mA
<Wizzup> it's just in epoll_wait(3, ...)
<Wizzup> but mine runs as root still
<freemangordon> you attach strace?
<Wizzup> sure
<freemangordon> ok
<Wizzup> weird, I am fully upgraded, but my xorg does not run as user
* Wizzup double checks repos
<freemangordon> how's that?
<Wizzup> well, I am on chimaera-devel
<Wizzup> and X runs as root
<Wizzup> well I have one day uptime
<Wizzup> let me reboot
<Wizzup> (logging a bit of strace first)
<Wizzup> does it also use more cpu when screen is off?
<Wizzup> or, more power, at least
<freemangordon> cpu is idle
<Wizzup> hmm
<freemangordon> maybe elogind behaves and opens some button
<freemangordon> wait
<freemangordon> Xorg runs as root here too
<Wizzup> oh
<Wizzup> was it about xinit running as user then?
<freemangordon> wait
<freemangordon> I edited xorg script
<freemangordon> lemme check what is in it
<freemangordon> ok, I don;t get that:
<freemangordon> user 2534 2522 0 16:17 tty7 00:00:00 /bin/sh /usr/bin/startx -- -keeptty -logverbose 1 -noreset -s 0 -core
<freemangordon> user 2564 2534 0 16:17 tty7 00:00:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :0 -keeptty -logverbose 1 -noreset -s 0 -core vt7 -keeptty -auth /tmp/serverauth.r2yeDGTndy
<freemangordon> root 2565 2564 1 16:17 tty7 00:00:05 /usr/lib/xorg/Xorg :0 -keeptty -logverbose 1 -noreset -s 0 -core vt7 -keeptty -auth /tmp/serverauth.r2yeDGTndy
<freemangordon> why Xorg runs as root?
<freemangordon> maybe it is normal, dunno
<Wizzup> I don't think it is normal
<Wizzup> when I type 'startx' as user on my laptop it runs as my user
<freemangordon> on my ubuntu 18 it runs as root too
<Wizzup> well, X, not Xorg
<Wizzup> ubuntu 18 is old, that's normal there
<Wizzup> merlijn 3424 0.0 0.0 4220 1672 tty1 S+ 12:42 0:00 xinit /home/merlijn/.xinitrc -- /etc/
<Wizzup> 11/xinit/xserverrc :0 -auth /tmp/serverauth.9uXoWqfL33
<Wizzup> merlijn 3425 2.0 0.3 1048196 58628 tty1 Sl 12:42 3:25 /usr/bin/X -nolisten tcp -keeptty :0 -auth /tmp/serverauth.9uXoWqfL33 vt1
<freemangordon> lemme check xserverrc
<freemangordon> but those are whatever comes from the repo
* freemangordon is confused
<freemangordon> user 2505 2504 0 14:26 tty7 00:00:00 /usr/lib/xorg/Xorg :0 -keeptty -logverbose 1 -noreset -s 0 -core vt7 -keeptty -auth /tmp/serverauth.SGsW4YyKuo
<freemangordon> this is VM
<freemangordon> Wizzup: what the?
<freemangordon> Wizzup: seems it has suid bit set:
<freemangordon> -rwsr-sr-x 1 root root 9796 Mar 12 20:01 Xorg.wrap
<freemangordon> but, it is the same on the VM, why it is different?
<Wizzup> what is Xorg.wrap ?
<freemangordon> a binary
<Wizzup> dpkg -S ?
<freemangordon> oh, wait
<freemangordon> I think I found it
<freemangordon> cat /etc/X11/Xwrapper.config
<freemangordon> gives root on d4 and user in the VM
<freemangordon> what the?
<freemangordon> -rw-r--r-- 1 root root 630 May 16 2021 /etc/X11/Xwrapper.config
<freemangordon> oh, scratch that
<freemangordon> my fault
<freemangordon> both have allowed_users=console
<Wizzup> did you find it, or not?
<freemangordon> no
<freemangordon> lemme check Xorg.wrap code
<Wizzup> fwiw I don't have Xorg.wrap on my laptop
<freemangordon> bt in VM there is
<freemangordon> *but
<freemangordon> and it still runs as user
<Wizzup> ok
<Wizzup> |-dsme---dsme-server-+-alarmd
<Wizzup> | |-autologin---startx---xinit-+-Xorg---{Xorg}
<Wizzup> | | `-Xsession-post-+-maemo-xinput-so---2*[{maemo-xinput-so}]
<Wizzup> freemangordon: doesn't dsmetool start autologin as root, or am I confused
<Wizzup> (I don't know much about autologin)
<Wizzup> yeah, autologin runs as root, is that intended? (could be)
<uvos__> ofc
<uvos__> autologin starts the session
<uvos__> it must be root
<Wizzup> ok
<Wizzup> startx seems to run at user as least
<Wizzup> freemangordon: what even runs this wrap stuff?
<uvos__> xinit
<uvos__> this dose some magic to make xorg able to run as user
<uvos__> its setuid and gives it some resources like keyboard and mouse devies or some sutch
<uvos__> iirc
<freemangordon> wait, I think I have an idea
<Wizzup> xinit is not setuit
<Wizzup> setuid*
<Wizzup> at least on my d4 it is not
<uvos__> warp
<uvos__> not xinit itself
<freemangordon> maybe DRM_IOCTL_MODE_GETRESOURCES fails on omap
<Wizzup> where do these wrap come from?
<Wizzup> I don't see them anywhere
<freemangordon> from xorg package
<freemangordon> see ^^^
<Wizzup> I see Xorg.wrap, but not xinit
<Wizzup> oh, I see
<freemangordon> will set needs_root_rights=no and will see
<Wizzup> ok
<freemangordon> user 2604 2603 5 16:53 tty7 00:00:04 /usr/lib/xorg/Xorg :0 -keeptty -logverbose 1 -noreset -s 0 -core vt7 -keeptty -auth /tmp/serverauth.7fOHNZMCmv
<freemangordon> but idle consumption is still very high
pere has quit [Ping timeout: 265 seconds]
norayr has left #maemo-leste [Error from remote client]
<freemangordon> maybe elogind opens some device and never closes it
<freemangordon> yep, it has several /dev/input/eventN fds
<Wizzup> ok, that's probably it then
<Wizzup> but elogind runs no matter if we have root X or not, no?
<Wizzup> why does elogind even have to open this? to read the power button?
<Wizzup> man :(
<Wizzup> it opens several more than once, too
<freemangordon> I guess it does its stuff when we have a session
<Wizzup> I don't think we want it to do -anything- with /dev/input
<freemangordon> mhm
<Wizzup> I need to go
<Wizzup> back later
* freemangordon checks in the code how to do that
<freemangordon> ok
<bencoh> sounds terrible tbh yeah
<freemangordon> ok, but how does mce uses power button with no issue?
<bencoh> doesn't mce close it when we disable display from hildon's UI?
<bencoh> (be it double-press on power button or lock screen)
<freemangordon> power button remains active when device is locked
<freemangordon> no, this is something else
<Wizzup> freemangordon: yes, that is kept open but kernelhas suspend iirc
<freemangordon> killing elognd does not help
<Wizzup> wrt power?
<freemangordon> mhm
<Wizzup> I think it confuses mce too
<Wizzup> I was unable to use ts on my d4
<uvos__> powerbutton (and cpcap keys in general) require no power to keep open
<freemangordon> right
<freemangordon> anyway, it is not elogind
<Wizzup> so just killing elogind is not enough, it confuses mce
<Wizzup> I am not sure if your test is valid
<freemangordon> ah
<freemangordon> lemme restart mce
<freemangordon> yeah
<freemangordon> cannot restart mce
<uvos__> so is it keeping the touchscreen event devices open (elogind)?
<uvos__> at any point
<freemangordon> will check
<uvos__> killing elogind might also not remove the problem
<uvos__> because it might have change the autosuspend tuneables
<uvos__> or it could be something else entirely
<Wizzup> uvos__: it has almost all open
<freemangordon> if elogind opens TS that might explain it, no?
<Wizzup> at all time
<uvos__> freemangordon: yes
<uvos__> that blocks ret
rafael2k_ has joined #maemo-leste
<Wizzup> feature creep at its best
<uvos__> i mean logind handling power isent feature creep
<uvos__> what this is is bad implementation
<uvos__> (it should release when configured to not handle it)
<freemangordon> you can't configure it
ceene has quit [Ping timeout: 276 seconds]
<Wizzup> uvos__: they go hand in hand
<Wizzup> :P
<uvos__> freemangordon: whitch one of these is ts?
<freemangordon> lemme check
<uvos__> the keyboard ones are not relevant
<freemangordon> but, lemme check something first
<uvos__> the kernel itself never closes those
rafael2k has quit [Ping timeout: 276 seconds]
<uvos__> (it keeps those open for the vts)
<Wizzup> I don' think we have 5 devices with power button
<uvos__> not but any device with EV_KEY
<uvos__> is open at all times by the kernel itself
<uvos__> so they dont matter
<uvos__> thats the keyboard and other stuff too
<freemangordon> still, elogind should not keep devices it is not interested in open
<Wizzup> unrelated but how does this work with ts keys
<uvos__> ts-buttons is "opertuneisitc"
<uvos__> ie it only reports keys when the touchscreen is open by some other source
<uvos__> yes this is a hack to work around this very problem
<Wizzup> heh
<freemangordon> what is the easiest way to check what is eventN?
<uvos__> freemangordon: right
<uvos__> ls -l /dev/input/by-path/
<freemangordon> ok, "Filtered touchscreen" is event2
<uvos__> or udevadm
<freemangordon> platform-mapphone_touchscreen-event -> ../event2
<uvos__> yeah that costs a tone of power
<freemangordon> lrwx------ 1 root root 64 Mar 14 17:23 20 -> /dev/input/event2
<freemangordon> right
<freemangordon> that seems like a bug to me
<freemangordon> not something intended
<freemangordon> I see in elogind code that it is supposed to close devices that has no buttons elogind is interested in
<uvos__> systemd-logind
<uvos__> dosent appear to have all events open
<uvos__> just a couple
<uvos__> out of 20 on my PC
<freemangordon> what is the version?
<uvos__> 253.1
<freemangordon> ummm....
<freemangordon> manager_all_buttons_ignored() :)
<freemangordon> lemme try that
pere has joined #maemo-leste
<bencoh> < Wizzup> feature creep at its best / and that's with a supposedly light/standalone version of elogind ... :/
<uvos__> im not sure how you expect logind to manage the session without knowing power key state and laptop lid state etc
<uvos__> its not feature creep at all
<freemangordon> didn't help :(
<uvos__> report a bug, its seams a bug
<uvos__> systemd must have fixed it after the fork
<freemangordon> well, I'll rather fix it and send a patch
<uvos__> sure
<Wizzup> uvos__: is your systemd-logind the same version
<freemangordon> no
<freemangordon> 253.1
<Wizzup> maybe it is solved in new elogind too
DPA has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
DPA has joined #maemo-leste
DPA has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
pere has quit [Ping timeout: 268 seconds]
DPA has joined #maemo-leste
uvos__ has quit [Ping timeout: 246 seconds]
uvos__ has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11> guys do you trust me if i say i'm chating with my wife on fb messenger using your conversations app ?
<Wizzup> haze and libpurple for facebook? :)
rafael2k_ has quit [Ping timeout: 246 seconds]
<Wizzup> I assume
<Wizzup> cool in any case :D
<arno11> no lol localhost gateway with bitlbee
<arno11> and through irssi in conversations
<arno11> yes really cool
<arno11> and almost no power ressources
<Wizzup> ah, check, that also works :D
<arno11> because bitlbee works with conversation it means
<Wizzup> yeah, we do need to support groups in conversations
<Wizzup> the code is there for it, kinda, but not in a release and UI for it is missing
uvos__ has quit [Ping timeout: 264 seconds]
<Wizzup> I have slack working telepathy-haze and purple-slack
<arno11> cool
<arno11> twitter signal and telegram should work as well
<arno11> using bitlbee
<Wizzup> I think this is libpurple, no?
<Wizzup> so this can also work with telepathy-haze
<bencoh> s/can/could/ I remember having issues with telepathy-haze and newer protocols (ie telegram) on fremantle
<arno11> it is another specific lib
<Wizzup> arno11: https://wiki.bitlbee.org/ says through libpurple
<Wizzup> (and extra lib ofc)
<bencoh> iirc the issue was with auth
<Wizzup> bencoh: all ssl on fremantle is no-go nowadays anyway
<bencoh> yeah I mean, before that
<arno11> yeah but it needs bitlbee plugin facebook
<arno11> and needs a hack
<arno11> with a .so file
<Wizzup> arno11: signal, or something else?
<arno11> bencoh: yeah but it works with a hack
<arno11> Wizzup: signal should work too
<Wizzup> arno11: in any case, if it wasn't clear (maybe it was): bitlbee and telepathy-haze can both use libpurple and thus theoretically work with most pidgin plugins
<Wizzup> so you can also definitely so slack on bitlbee, like I did for tp-haze
<Wizzup> not pushing for any direction, just FYI
<Wizzup> let me see if I can get my n900 attached to this serial
<Wizzup> freemangordon: re: elogind, what do we plan to do, fix it and build ourselves until next release?
<Wizzup> bookworm also has 246
<arno11> Wizzup:ok everything is clear
<Wizzup> :)
<freemangordon> Wizzup: yeah, sounds like a plan
<freemangordon> but it is extremely hard to find where are those opened
<Wizzup> no surprise there :D
<Wizzup> does it use libinput?
<freemangordon> what I think happens here is that is kinda "shadows" the real devices for user session
<Wizzup> freemangordon: and if we set HandleLidSwitch=ignore, and same for all the others, does it still open event files?
<freemangordon> yes
<freemangordon> because those get opened by session_device_open()
<freemangordon> this is a result of a dbus call
<Wizzup> ok
<Wizzup> hmm..
<Wizzup> >Only input devices with the "power-switch" udev tag will be watched for key/lid switch events.
<freemangordon> yes, but we hit something differenet
<freemangordon> maybe when session process opens a device, this gets opened by elogind too
<Wizzup> ok
<Wizzup> that would be absolutely insane @ mirroring
<Wizzup> or shadowing
<Wizzup> that can't be it
<freemangordon> see https://pastebin.com/w9zmNPGm
<freemangordon> this is for "/dev/input/event5"
<freemangordon> in VM
<freemangordon> ok, leme retry with dbus-monitor
<Wizzup> maybe this is the 'tracking' that it does or something
<freemangordon> could be
<Wizzup> I just confirmed that setting *all* of the HandleBlaBla=ignore doesn't help
<freemangordon> already tried, but ok
<Wizzup> didn't know that
<freemangordon> se, this is TakeDevice method
<freemangordon> *so
<freemangordon> "TakeDevice() allows a session controller to get a file descriptor for a specific device."
<Wizzup> it seems to be somehow facilitating libinput
<freemangordon> oh, ok
<freemangordon> sec
uvos__ has joined #maemo-leste
<freemangordon> see this
<Wizzup> sigh
<Wizzup> I guess we will probably have to add logind specific code to tell it to drop the devices, just disabling it in xorg isn't enough
<freemangordon> it should be
<freemangordon> or rather
<freemangordon> xf86DeleteInput() calls systemd_logind_release_fd
<freemangordon> Wizzup: we have to add code where?
<freemangordon> Wizzup: uvos__: what do we use now to disable input devices?
<freemangordon> XInputDisable?
* freemangordon checks mce code
<freemangordon> x11_set_input_device_enabled
* freemangordon wonders where this end up in server code
<Wizzup> x11_set_input_device_enabled that sounds like a helper function in mce
<Wizzup> or is this libinput?
<freemangordon> sorry, helper
<freemangordon> XIChangeProperty
<freemangordon> "Device Enabled" atom it seems
<freemangordon> p, li { white-space: pre-wrap; } XI_PROP_ENABLED
<Wizzup> yeah, that sounds like normal X way
<freemangordon> ok, but where this ends up?
<Wizzup> don't know
akossh has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
<freemangordon> Wizzup: ok, seems we will have to cheat
<Wizzup> sounds fun :D
<freemangordon> xorg does not support releasing input devices, but elogind can 'pause' them
<freemangordon> in order to do that we should activate another session
<freemangordon> not sure how to do that though
<Wizzup> oh god
<Wizzup> can we just not have xorg tell elogind about input devices?
<freemangordon> no
<freemangordon> multi-session will not work then
<freemangordon> as xork will keep devices open
<freemangordon> *xorg
<Wizzup> does this bother us?
<freemangordon> well
<freemangordon> lemme check something
<Wizzup> btw, what do you mean, xorg does not support releasing input devices
<Wizzup> you can definitely get xorg to close the fds
<freemangordon> do you know where that happens?
* freemangordon checks if this is fixed in upstream xorg
<Wizzup> no, I will have to look, but I can try to see
<Wizzup> I mean we know xorg closes them for a fact, that's why without elogind, things work fine
<Wizzup> pm wise
<freemangordon> yes
<Wizzup> freemangordon: dix/devices.c DisableDevice ?
<freemangordon> (void) (*dev->deviceProc) (dev, DEVICE_OFF);
<Wizzup> you can break on that in gdb for sure
<freemangordon> yeah
<Wizzup> seems to call Disable() on whatever the abstract driver is, if hw/kdrive/src/kinput.c is the right place to look
<freemangordon> what is kdrive in that contaxt?
<Wizzup> not sure
<freemangordon> *context
<Wizzup> I can't find another more reasonable place/file where DEVICE_OFF is used
<freemangordon> hmmm
<freemangordon> DisableDevice is not called in the VM
<freemangordon> when I lock the screen that is
<freemangordon> neither is DeviceSetProperty
<freemangordon> what the?
<Wizzup> maybe this is libinput magic
<freemangordon> xinput --set-prop 12 "Device Enabled" 0 makes it hit the breakpoint
<Wizzup> what does mce do then?
<freemangordon> maybe mce does not work properly in VM
<Wizzup> (if not that)
<freemangordon> no idea
<freemangordon> uvos__: ^^^?
<Wizzup> lol this is really quite hilarious, it doesn't seem to ever release fds unless it fails to grab them or something
<freemangordon> Wizzup: yes, because xorg does not control those fds anyways
<freemangordon> it is elogind that does it
<Wizzup> none of this makes any sense to me, but I am probably just grumpy
<freemangordon> and it just send PauseDevice signal
<freemangordon> imagine, if you switch the session
<freemangordon> your active session should receive kbd input, no?
<Wizzup> I don't see why X cannot close input devices if it is not active, but I guess there is no point in discussing why elogind works the way it does
<Wizzup> we can't change that anyhow
<freemangordon> because it didn;t opent them in first place :)
k1r1t0 has quit [Ping timeout: 276 seconds]
<Wizzup> freemangordon: if it does open them in the first place, it's fine
<Wizzup> also keep in mind that most input devices can be opened many times
<freemangordon> well, we'd better fix that properly
<Wizzup> why can't elogind let go of the fd?
<Wizzup> I don't see how that factors in to the switching
<freemangordon> elogind will close fds, if we somehow tell it to do so
<Wizzup> so why doesn't X?
<freemangordon> like, switch the session
<freemangordon> because X just asked elogind to open fds for it
<freemangordon> anyway
<Wizzup> so:
<freemangordon> this makes sense to me
<Wizzup> xorg without elogind:
<Wizzup> 1. opens input devices by default
<Wizzup> 2. when input disabled, closes fd
<Wizzup> why can't it do the same with elogind?
<freemangordon> I think this is more complicated
<freemangordon> it seems this is libinput that does the magic
<freemangordon> ummm
<freemangordon> sorry
<freemangordon> Thread 1 "Xorg" hit Breakpoint 4, 0x00007f459b5c18a0 in ?? () from /usr/lib/xorg/modules/input/libinput_drv.so
<freemangordon> libinput_drv.so
<freemangordon> Wizzup: this ends up in xf86libinput_off() which in turn calls xf86SetIntOption(pInfo->options, "fd", -1);
<Wizzup> ok
<freemangordon> and where this ends is the million dollars question :)
<freemangordon> Wizzup: I don't get that note
<Wizzup> (sry, work mtg)
<freemangordon> ok
norayr has joined #maemo-leste
<Wizzup> back
DPA has quit [Ping timeout: 276 seconds]
arno11 has joined #maemo-leste
<freemangordon> Wizzup: maybe I can patch xorg to ReleaseDevice() on disable
<freemangordon> but, maybe we shall drop logind session (and run Xorg as root) until done
<freemangordon> it will take me some time to patch it
<arno11> Sorry guys but is there a magic command to get pin entry code working or is it broken on n900 ?
<freemangordon> BTW, didn;t mce use dpms to disable devices?
<freemangordon> pin entry? SIM pin?
<arno11> sim pin
<freemangordon> it should work
<freemangordon> arno11: sorry, my comment was not very helpful :)
<arno11> ok lol no probs
<arno11> you're working hard i know
<freemangordon> does ofono report that SIM requires PIN?
<arno11> nope nothing happened in fact
<arno11> ofono is not ready
<Wizzup> freemangordon: well for non-devel chimaera we have this, right?
<freemangordon> yes
<freemangordon> arno11: well, of ofono is not ready...
<freemangordon> *if
<arno11> always this message
<Wizzup> arno11: does ofono see the modem?
<arno11> no
<freemangordon> Wizzup: ok, will see what I can do during the weekend
<arno11> freemangordon:i mean sms app says: ofono is not ready
<Wizzup> I am fine with running X as root fwiw
<Wizzup> arno11: mdbus2 is probably a good way to debug ofono's state
<Wizzup> and fwiw startup-pin-query is the program to run for getting the pin gtk dialog
<arno11> ok i'll try
<Wizzup> (normally it runs on boot)
<arno11> ok thx guys
<Wizzup> you can dpkg -i it I think
<arno11> cool
<sicelo> or ofono-scripts
<sicelo> output of ` sudo dmesg | grep 'modem\|ssi' ` might also be interesting to see
<arno11> ah ok
<Wizzup> I find ofono-scripts less useful, but yes, that can work too
<arno11> interesting
<arno11> i'll try all of that and let you know guys
<arno11> thx
<freemangordon> Wizzup: startup-pin-query is *not* run on boot :)
<freemangordon> it is run by status menu plugin once SIM/modem is ready
<freemangordon> ugh
<Wizzup> freemangordon: so effectively on boot :P
<freemangordon> I hope this is in chimaera
<Wizzup> should be, I use it daily
<freemangordon> no, if you boot d4 with no SIM and then hot-plug, it will *then* ask you
<freemangordon> ok, it is in chimaera, but not in master
<freemangordon> lemme fix that
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup> uvos__: on my laptop:
<Wizzup> # ls -lsh /proc/2408/fd | grep event | grep input | wc -l
<Wizzup> 17
<Wizzup> elogind opened just about every eventX that existed
uvos has joined #maemo-leste
<uvos> what version is that
<uvos> are any of the previous questions to me still relevant wrt mce etc?
<uvos> dpms is not relevant to input devices
<uvos> this is for crts
<uvos> *crtcs
<buZz> dpms likely gets stopped by input devices?
<uvos> xorgs dpms extension manages crtc state based on input devices yes, avoid that is why we disable all input devices on blank, instead of just the ts
<uvos> but this is not relevant to this discussion
<Wizzup> uvos__: 246.10-r2
<uvos> one annyoing thing with startup-pin-query is that if you accidentaly click above it (ie dissmissing it) there is no way to get it back
<uvos> but that would be a easy fix with a .desktop file to runn it again
<Wizzup> you can go to settings and get it back
<Wizzup> settings->phone
<Wizzup> but yes
<Wizzup> this is something we'll have to fix later/eventually
pere has joined #maemo-leste
DPA has joined #maemo-leste
DPA has quit [Ping timeout: 246 seconds]
DPA has joined #maemo-leste
maemish_ has joined #maemo-leste
Langoor has quit [Remote host closed the connection]
Langoor has joined #maemo-leste
DPA has quit [Ping timeout: 276 seconds]
DPA has joined #maemo-leste