<diejuse1> qt+
<diejuse1> qt
<diejuse1> mpv and gnome-mpv work fine, but not hildonized hehe
<diejuse1> I have found better option: mpv with SMPlayer
<Wizzup> maybe we should have it preinstalled if it works well (through some extras meta pkg)
<diejuse1> try it, it's good
<diejuse1> I am looking for the best applications to do the basic functions.
<Wizzup> great, please share documentation and such - we need that :)
<diejuse1> I promise I will do
Oksana has quit [Remote host closed the connection]
Oksana has joined #maemo-leste
Pali has quit [Ping timeout: 265 seconds]
Oksana has quit [Remote host closed the connection]
Oksana has joined #maemo-leste
kvw_5_ has joined #maemo-leste
kvw_5 has quit [Ping timeout: 246 seconds]
cockroach has quit [Quit: leaving]
diejuse1 has quit [Ping timeout: 252 seconds]
inky has quit [Ping timeout: 240 seconds]
_whitelogger has joined #maemo-leste
_whitelogger has joined #maemo-leste
pagurus has quit [Ping timeout: 240 seconds]
belcher has quit [Ping timeout: 252 seconds]
belcher has joined #maemo-leste
jrayhawk has quit [Quit: leaving]
lyubov has quit [Quit: WeeChat 3.0]
inky has joined #maemo-leste
tmlind has quit [Quit: leaving]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
mardy has joined #maemo-leste
tmlind has quit [Quit: leaving]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
<freemangordon> Wizzup: uvos: how to simulate tklock crash?
* enyc meows
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
tmlind has quit [Client Quit]
tmlind has joined #maemo-leste
diejuse1 has joined #maemo-leste
jameshjacks0njr has quit [Ping timeout: 276 seconds]
jameshjacks0njr has joined #maemo-leste
jameshjacks0njr has quit [Max SendQ exceeded]
jameshjacks0njr has joined #maemo-leste
diejuse1 has quit [Quit: Leaving.]
diejuse1 has joined #maemo-leste
Pali has joined #maemo-leste
RedW has quit [Ping timeout: 258 seconds]
RedW has joined #maemo-leste
uvos has joined #maemo-leste
pere has quit [Ping timeout: 240 seconds]
<uvos> clougps crashes bu i think that just pvr
<uvos> freemangordon: use any sdl1 ap
<uvos> brainparty
<uvos> etc
<uvos> tklock should not try to lock sdl1 is fullscreen as it holds a grab
<Wizzup> freemangordon: also, apt upgrade to our latest libsdl1.2
<uvos> also you can show that tklock is not holding a grab in normal instances using any app that uses xgrabkey for a global shortcut
<uvos> hildon with the mapphone buttons works fine for instance
<uvos> also btw i dont think the code ever worked
<uvos> because in hildon they had some code that disabled ctrl-backspace if tklock was active
<uvos> witch tells me they where hacking around the symtoms of xgrabkeyboard not working in tklock
<uvos> as otherwise thats not nessecary at all
<uvos> as hildon cant get any input anyhow if tklock grabs the keyboard
pere has joined #maemo-leste
<freemangordon> hmm, ok
<freemangordon> Wizzup: 1:1.2.15+leste1-6+2m7 ?
<freemangordon> May 20 12:11:26 localhost systemui-tklock[10111]: gp_tklock_try_grab:95:GRAB FAILED, gp_tklock can't be enabled#012request display unblank
<Wizzup> freemangordon: I think that's the one yes
<freemangordon> so, no crash or misbehaviour
<freemangordon> cannot reproduce in the VM
<Wizzup> I don't think it should unblank the display in this case
<Wizzup> maybe the crash comes from pvr as uvos said
<freemangordon> sure it should
<freemangordon> because mce blanked it
<uvos> it should, however not open
<uvos> at all
<freemangordon> hmm? sorry, can;t parse
<uvos> it should not open
<uvos> as in not show
<uvos> it shows for me
<freemangordon> what happens here is that:
<freemangordon> 1. there is no crash.
<freemangordon> 2. brainparty stays on to with no tklock shown
<freemangordon> so, I don;t really see any issue
<freemangordon> *on top
<uvos> thats wierd
<uvos> try on d4
<freemangordon> why it should be different there?
<uvos> idk but it is for me
<freemangordon> btw, my tklock is latest mater
<freemangordon> *master
<uvos> also to dosent hold a grab
<uvos> try that part
<freemangordon> how:
<freemangordon> how?
<uvos> set shortcuts.ini in hildon to something
<uvos> but wait
<uvos> let me check something
<freemangordon> ok
<freemangordon> maybe your mce is misbehaving?
diejuse1 has quit [Quit: Leaving.]
pere has quit [Ping timeout: 245 seconds]
<uvos> i dont see how mce can affect tklock holding a grab
<freemangordon> also, why is brainparty started in portrait?
<uvos> freemangordon: brainparty is started in landscape
<freemangordon> not in the VM
<uvos> its renders itself 90degree
<freemangordon> ah :)
<freemangordon> what is your tklock version?
<uvos> i cant find the device :D
<freemangordon> :D
<Entitlement> freemangordon - [ debian/changelog: bump for 0.4.2 · maemo-leste/osso-systemui-tklock@23ee110 · Gi... ]
<uvos> ha found it
<freemangordon> nice :)
<uvos> almost got put in the washing machine :P
<Wizzup> lol
<Wizzup> need another one? :P
<uvos> not yet
<uvos> soon maybe if this conintues :P
<uvos> 0.4.2+2m7.1
<uvos> freemangordon:
<uvos> and i can open brainparty
<freemangordon> ok, that's the latest
<uvos> and then lock the device and it becomes glichy
<uvos> also i can open tklock
<uvos> and then press android "home"
<uvos> and the launcher appears above tklock
<freemangordon> oh, my device is with glibc from chimaera
<freemangordon> with no h-d working
<freemangordon> :(
<freemangordon> uvos: could you check what is written in syslog
<freemangordon> also, how do you lock the device?
<uvos> freemangordon: power button
<uvos> witch i reasigned to tklock
pere has joined #maemo-leste
<uvos> if i use the power menu every thing works
<uvos> but thats becaus sdl releases the grab in this case
<uvos> as it becomes a window
<Entitlement> uvos - [ leste-config/shortcuts.ini.leste at master · maemo-leste/leste-config · GitHub ]
<freemangordon> ah, wait, I think I triggered the bug
<uvos> you can use this shortcuts.ini
<uvos> to trigger the failed grab bug
<freemangordon> does it happen for you if you double-press the power button?
<uvos> freemangordon: i have double press reaisgned to something else
<uvos> but single press is assinged to tklock for me
<uvos> if you put the above shortcuts ini onto vm and press f10 in tklock
<uvos> you can repo the other bug
<freemangordon> well, I guess it is the same bug
<uvos> yeah
<uvos> different aspects
<freemangordon> hmm, wait, what happens here (on power button double-press) is:
<freemangordon> 2. 3*200ms later display unblanks
<freemangordon> 1.display blanks
<freemangordon> which is the expected behaviour
<freemangordon> so actually I still cannot reproduce it
<freemangordon> uvos: how did you reassign single-press to tklock?
<freemangordon> also, may I have your syslog when it happens on your device
<uvos> freemangordon: just switch arround https://github.com/maemo-leste/mce/blob/3f92150a6094f504e3600d8c394221c7faa7fb8e/mce.ini#L51 and PowerKeyDoubleAction
<Entitlement> uvos - [ mce/mce.ini at 3f92150a6094f504e3600d8c394221c7faa7fb8e · maemo-leste/mce · GitH... ]
<freemangordon> hmm:
<freemangordon> May 20 12:41:54 localhost systemui-tklock[10111]: systemui_do_callback:53:Invalid callback
<uvos> freemangordon: buy copy [PowerKey] to 99-user.ini first
<freemangordon> and I saw visual tklock for a split second
<freemangordon> so there *is* something buggy
<uvos> freemangordon: yeah thats what happesn forme
<uvos> freemangordon: and then tklock is running under brainparty
<freemangordon> do you see "invalid callback" message in syslog?
<uvos> let me check
<uvos> freemangordon: yes
<uvos> but try the other repo method
<uvos> its mutch more visually obvious when it tirggers
<Entitlement> freemangordon - [ osso-systemui-tklock/osso-systemui-tklock.c at master · maemo-leste/osso-systemu... ]
<Entitlement> freemangordon - [ osso-systemui-tklock/osso-systemui-tklock.c at master · maemo-leste/osso-systemu... ]
<uvos> also you can unlock tklock tough brainparty
<uvos> by swiping at the right point
diejuse1 has joined #maemo-leste
<freemangordon> uvos: could you build tklock with "DEB_BUILD_OPTIONS="noopt nostrip" CFLAGS="-DDEBUG" dpkg-buildpackage -rfakeroot -b", install it and provide syslog?
<freemangordon> pull latest master please
<freemangordon> as this seems to be timing issue and VM is too fast compaer to d4
<freemangordon> *compared
<uvos> freemangordon: not right now sorry
<freemangordon> sure, when you have time
diejuse1 has quit [Client Quit]
<kek> MerlijnWajer created a repository: https://github.com/maemo-leste/python-conic
<Wizzup> btw: python-conic should be available imminently, I imported and hack-fixed the build system for modrana purposes mostly, but it can be used to monitor/parse IAPs etc
diejuse1 has joined #maemo-leste
<inky> The repository 'https://maedevu.maemo.org/leste-devel beowulf Release' does not have a Release file.
<inky> N: Updating from such a repository can't be done securely, and is therefore disabled by default.
<Wizzup> I think you are not using -devel properly
<inky> oh that's probably not leste-devel but beowulf-devel
<inky> wiki doesn't mention that explicitly, i needed to guess.
<Wizzup> I think it should
<Wizzup> it's like this:
<Wizzup> deb https://maedevu.maemo.org/leste beowulf-devel main contrib non-free droid4
<Entitlement> Wizzup - [ Directory Index - Maemo Leste ]
<Wizzup> ofc don't use droid4 component if you don't use droid4
<Wizzup> inky: yeah, it's not on the wiki apparently
<freemangordon> omg, brainparty plays music in the VM :)
<Wizzup> :p
<Wizzup> probably quite loudly, too
<uvos> brainparty plays music on d4 too
<uvos> audio works by default now
<Wizzup> yeah, it just needs scaling
<diejuse1> how can I change the hour? I have wrong time
<Wizzup> diejuse1: status -> clock and alarms -> click on time
<Wizzup> modrana espeak works
<Wizzup> :p
<diejuse1> ok, it doesn't work for me
<Wizzup> diejuse1: what do you see?
<diejuse1> There is no answer when I press on the time
<Wizzup> what if you go to settings -> date and time
<diejuse1> mmm "date and time" is not in settings
<diejuse1> I must have a conflict
<diejuse1> what is the name of the package related to "date and time" for reinstalling?
<inky> interesting. virtual keyboard works in vim (debian's)
<inky> but not in dino.
<inky> i think the problem is that
<inky> virtual keyboard does not appear
<uvos> press search
<inky> search?
<uvos> the search key on device
<inky> hardware button?
<uvos> yes
<uvos> or vol up on pp
<inky> hmmm cannot trigger it. :/
<inky> and on pinephone? i have no pinephone.
<inky> mine is droid4
<uvos> ok so you need hildon desktop from devel
<uvos> and him from devel
<inky> i got it
<inky> i can type in vim
<inky> with vkbd
<uvos> vim runs in osso-xterm
<uvos> thats totaly different and unrelated
<inky> debian's vim?
<inky> ok.
<inky> but
<inky> i added devel, did upgrade
<inky> and
<uvos> press Home button on device
<inky> shows all windows
<uvos> ok
<uvos> so that part is working
<uvos> but search dosent open vkb (just at hildon-desktop no app shown)?
<Wizzup> maybe he hasn't rebooted (to get new hildon-input-method running)
<uvos> true
<freemangordon> uvos: still cannot reproduce the bug, even after visual tklock is shown, it is removed in 600ms
<uvos> can you repoduce the other path?
<freemangordon> didn;t try
<inky> i did. but let me reboot once more
<uvos> if you have a d4 running should be trivial
<uvos> just press home button at tklock
<Wizzup> inky: you are 'apt upgrade' up to date?
<freemangordon> but, lunch first, bbl
Oksana has quit [Remote host closed the connection]
<freemangordon> uvos: I don;t
<uvos> you dont what?
<freemangordon> "have d4 running"
Oksana has joined #maemo-leste
<uvos> oh ok
<freemangordon> becuase it is setup for pvr 1.17 development
<uvos> ok
<uvos> create shortcuts.ini then
<inky> aaa search button!
<freemangordon> :D
<inky> yes that's the 'lupe' i got it.
<inky> it works!
<uvos> yeah android search button
* freemangordon is afk
<Wizzup> so for anyone who wants to try it before package, 'apt install python-conic', 'git clone https://github.com/M4rtinK/modrana -b n900-branch' and from 'modrana' run 'python modrana.py -u GTK -d n900'
<Entitlement> Wizzup - [ GitHub - M4rtinK/modrana: ModRana is a flexible GPS navigation system for mobile... ]
<inky> so did you handle that trigger for each device separately?
<Wizzup> before it's packaged*
<uvos> inky: yes
<uvos> inky: its search on d4 and bionic and vol up on pp and dosent exist on n900
<inky> wow. even doesn't exist on n900. no free button? (:
<Wizzup> inky: the free button is your hardware keyboard
<uvos> yes its bound to something on d4 only because it shares a config file with bionic
<diejuse1> I have seen I don't have "libcpdatetime.so" in /usr/libs/hildon-control-panel
<diejuse1> How can I install it?
diejuse1 has quit [Quit: Leaving.]
<Wizzup> $ dpkg -S /usr/lib/hildon-control-panel/libcpdatetime.so
<Wizzup> applet-datetime: /usr/lib/hildon-control-panel/libcpdatetime.so
<inky> Wizzup, uvos, but on n900 (i don't remember) do i have some shortcut to trigger the vkb?
<Wizzup> no
<inky> on hwkbd
<Wizzup> you can trigger the special keys though
<Wizzup> like always
<inky> that may be the problem. i mean, i have the hardware kbd on droid here, but it's not enough, i needed the vkbd, and i got it and i am happy.
<inky> but i wouldn't be happy on n900 if i cannot trigger it to appear.
<inky> i cannot use all those languages that vkbd has with hwkbd.
<Wizzup> what is the problem?
<inky> i don't only type latin.
<inky> well not only me. (;
<Wizzup> I type cyrillic on the hw kb
<Wizzup> maybe there is a way to raise the normal kb with a key in fremantle, idk
<inky> my current problems are solved. yes but there are more virtual layouts than hardware.
<Wizzup> do you mean you have not enough keys?
<inky> firstly, there are no layouts. secondly, yes, not enough keys.
<inky> i just looked at droid's keyboard - well it's possible to prepare an xkb map
<inky> because it has numbers
<inky> so i can, but i don't even want to use hwkbd with some strange layout. onscreen is enough.
<inky> also my friend uses pinephone and i hope he'll stick with leste.
<Wizzup> well, then see how it is done in fremantle maybe :)
<uvos> Wizzup: no
<inky> and pp has no hwkbd. so i think onscreen is the main kbd we have.
<uvos> inky: just setup shortcuts.ini to raise the vkb on whatever combination you like
<inky> sorry i don't use n900 and i talk about n900 user needs.
<uvos> we can make raise vkb ctrl-alt-v on n900
<inky> i am totally fine now with what i have on droid and what i believe my friend will have on pinephone once i upgrade his device.
<uvos> i just dont see mutch point
<uvos> its user configuarble anyhow
<inky> uvos having something would be great.
<Wizzup> blue arrow + ctrl is what raises it in normal him apps
<Wizzup> on n900
<inky> but shouldn't user configurable have some default config?
<Wizzup> inky: I think if you dig into it you'll find that all of it is there, and you just need to configure the shortcut
<Wizzup> if I read uvos correctly
<inky> i don't use n900 (i may one day) and i am totally happy that i can raise vkbd on droid4 and pinephone.
<kek> MerlijnWajer edited a repository: https://github.com/maemo-leste/python-conic
<inky> thank you. we can over that. if i have such a device, and i won't find info on shortcuts.ini i'll ask.
<Wizzup> I think apart from python-mawf we have most of the maemo specific packages ported (from fremantle to leste)
<inky> so what do we use for gps? liblocation or gpsd?
<inky> i had an app in maemo that used gps. decentralized location sharing via xmpp. it needs a lot of rethinking though.
<inky> all packages ported sounds very cool.
<Wizzup> what was the app called?
<Wizzup> leste uses gpsd in the background, but liblocation is the api to use
<uvos> also that might change in the future
<uvos> might be liblocation over geoclue at some point
<uvos> so i would avoid using gpsd directly
BenLand100 is now known as TheDoctor
TheDoctor is now known as BenLand100
<Entitlement> Wizzup - [ Motorola Droid Xyboard 8.2" MZ609 16GB, Wi-Fi + 4G (Verizon) - BLACK (47152) 723... ]
<Wizzup> (just cleaning out old tabs and had this open apparently)
<Wizzup> parazyd: freemangordon: did we ever package/use this? https://github.com/maemo-leste/osso-systemui-splashscreen
<Entitlement> Wizzup - [ GitHub - maemo-leste/osso-systemui-splashscreen: System UI splashscreen plugin ]
R0b0t1 has quit [Ping timeout: 240 seconds]
<parazyd> Not that I recall
R0b0t1 has joined #maemo-leste
<freemangordon> looks like, though I think we should
<Wizzup> do you mean 'looks like we did not' ?
<kek> parazyd opened an issue: https://github.com/maemo-leste/bugtracker/issues/537 (gtk3 hildon-input-method-framework port)
<kek> parazyd assigned an issue: https://github.com/maemo-leste/bugtracker/issues/537 (gtk3 hildon-input-method-framework port)
<kek> parazyd labeled an issue: https://github.com/maemo-leste/bugtracker/issues/537 (gtk3 hildon-input-method-framework port)
<kek> parazyd milestoned an issue: https://github.com/maemo-leste/bugtracker/issues/537 (gtk3 hildon-input-method-framework port)
<freemangordon> Wizzup: "looks like we did not, though I think we should"
<freemangordon> it is packaged, we shall only build that
<Wizzup> ok
<Wizzup> I forgot what it is for, it is not part of the bootup, right?
<freemangordon> it shows the white poweroff screen
<freemangordon> and some more
<uvos> except mce turns off the display in poweroff state...
<uvos> and on bootup we wanted to look into useing plymouth
<Wizzup> yes @ plymouth, that's why I asked
<Wizzup> I wasn't sure if it was related
<freemangordon> it is not used in bootup
<Wizzup> ok
<uvos> freemangordon: ok
<uvos> freemangordon: still white power off screen is not usefull
<Wizzup> will built it today unless parazyd beats me to it
<uvos> Wizzup: xyboard should mostly just work
<parazyd> ah that repo is ready
<parazyd> I can try to build it now, sure
<Entitlement> freemangordon - [ osso-systemui-splashscreen/osso-systemui-splashscreen.c at master · maemo-leste/... ]
<uvos> Wizzup: afaik it needs some display patches and thats it
<Entitlement> freemangordon - [ osso-systemui-splashscreen/osso-systemui-splashscreen.c at master · maemo-leste/... ]
<Wizzup> uvos: sounds like it might be fun to get some and toy with them
<uvos> Wizzup: so... i gues you could get one
<freemangordon> I guess we'll need media files as well
<uvos> Wizzup: idk how usefull it is to support a obscure old tablet
<Wizzup> could be nice to manage stuff at home
<parazyd> ah
<uvos> but it would be nearly 0 effort
<parazyd> :p
<Wizzup> mount it somewhere
<freemangordon> uvos: 'tklock bug' is either in tklock or in mce, I am still not sure
<uvos> freemangordon: the failure to grab the keyboard cant possibly be in mce
<freemangordon> I don;t see grab failure here
<freemangordon> well, ok
<freemangordon> I see grab failure but display is not locked
<freemangordon> and grab failure is to be expected, no?
<uvos> no
<freemangordon> why?
<uvos> visual tklock _must_ grab when its shown
<uvos> otherwise you can interact with other clients beneath it
<uvos> this breaks security
<freemangordon> it is shown for half a second only, and then it is destroyed
<uvos> freemangordon: no when no other client is grabbing the keybaord
<uvos> it must grab it
<uvos> it dosent
<uvos> just hildon-desktop + tklock no thing else running exposes this
<uvos> visual tklock is not holding a grab
<freemangordon> well, but with brainparty grad is expected to fail, no?
<uvos> yes
<uvos> thats a different issue
<uvos> if nothing else holds grab = tklock must grab
<freemangordon> I can;t reproduce failed grab
<uvos> how are you trying to repo?
<freemangordon> with h-d only
<freemangordon> by double-press the power button
<freemangordon> and then pressing the keyboard
<freemangordon> nothing happens
<uvos> thats totaly unrelated
<uvos> thats unrelated
<freemangordon> ok, please provide steps to reproduce
<uvos> any application that uses xgrabkey
<freemangordon> like?
<uvos> will still get its grabed key if tlock is active
<uvos> like hildon-desktop with any shortcuts configured
<uvos> or any app with a global shortuct
<uvos> also any app that calls xsetinput on itself will get input
<freemangordon> wait, isn;t hildon-desktop with shortcuts configured the default state?
<uvos> temporarly no
<freemangordon> so, you say that ctrl-backspace works with visual tklock enabled?
<uvos> no
<freemangordon> I don;t get it that
<uvos> there is explicet code in hildon to stop that
<uvos> any other shortcut
<freemangordon> ctrl-shift-x?
<freemangordon> (to start terminal)?
<uvos> i think there is explicet code for that one too
<uvos> try the new ones
<uvos> i added
<uvos> they dont work when brain party is running
<freemangordon> do you have a config to provide?
<freemangordon> oh, you did
<Entitlement> uvos - [ leste-config/shortcuts.ini.leste at master · maemo-leste/leste-config · GitHub ]
<uvos> because brainparty holds a grab
<uvos> thats expected
<uvos> tklock however is not holding a grab
<uvos> so they work with tklock active
<Entitlement> freemangordon - [ leste-config/shortcuts.ini.leste at master · maemo-leste/leste-config · GitHub ]
<uvos> yes
<uvos> just change the keys maybe
<freemangordon> ok
<freemangordon> uvos: so, which application to use to test the grab?
<uvos> brainparty is fine
<freemangordon> I mean - what is the criteria if tklock grab works or not
<uvos> i accually use the sdl test suite
<freemangordon> but, as I said, with brainparty tklock fails to get grab and thats expected
<uvos> freemangordon: the sdl test suite
<uvos> you can start it via command line
<uvos> and it will fail the fullscreen test
<freemangordon> what package is that?
<uvos> because it cant get a grab if a grab is allready taken
<uvos> freemangordon: there is no package
<freemangordon> but?
<uvos> i compiled it while working on sdl2
<freemangordon> where to get that from?
<uvos> i compiled it while working on sdl1
<freemangordon> I shall clone the repo and build?
<uvos> but hildon-desktop shows the same thing
<freemangordon> how do you see it?
<uvos> if you open tklock and use a shortcut
<uvos> if a grab is held
<freemangordon> and?
<uvos> hildon should not get the keys
<freemangordon> how to see that left mous button is clicked, for example?
<uvos> ?
<uvos> left mouse?
<freemangordon> how do you see if hildon gets keys or not while in tklock?
<freemangordon> from syslog?
<uvos> the shortcuts will activate
<freemangordon> and how do you know that a shortcut is activated?
<Entitlement> freemangordon - [ leste-config/shortcuts.ini.leste at master · maemo-leste/leste-config · GitHub ]
<freemangordon> which one to use?
<uvos> well LeftButton minimizes tklock and opens tasknav
<uvos> and RightButton kills tklock
<freemangordon> ok
<uvos> they all work
<uvos> RaiseVkb opens the vkb
<freemangordon> oh, ok, now I *think* I understand the 'bug'
<uvos> explain
<freemangordon> so, the bug can be triggered only when we have visual tklock active
<freemangordon> right?
<uvos> right
<freemangordon> not when the display is blanked
<uvos> non visaul tklock works fine maybe
<uvos> sice mce disables input anyhow
<uvos> mce disables all input
<uvos> what tklock dose dosent matter
<uvos> when display is blanked
<freemangordon> I see
<inky> Wizzup, uvos: that was the app: http://norayr.am/meridian23/
<freemangordon> uvos: see https://pastebin.com/XpuMiwDh
<Entitlement> freemangordon - [ May 20 15:40:50 localhost systemui-tklock[13482]: Method call received from: :1.... ]
<inky> this page was made i don't know how many years ago. 2012 i believe.
halftux has joined #maemo-leste
<freemangordon> esp the 'release_grabs' part :)
<Wizzup> halftux: fwiw my gpg key is on the keyservers, just pull new one in
<freemangordon> this is what happens when vtklock is activated :)
<uvos> ya well vt should hold the grab
<uvos> thats the entire issue
<freemangordon> ok, it is clear to me now
<uvos> we dont even really need non visual tklock
<freemangordon> on n900 you can unlock with a slider button as well
<halftux> ah I see great thx
<uvos> freemangordon: that works fine
<uvos> freemangordon: mce unlocks in this case
<freemangordon> but, it unlock through non-visual tklock
<freemangordon> *unlocks
<freemangordon> also, mce disabling keyboard is a temporary hack, IIRC
<Wizzup> it's also for power saving
<uvos> freemangordon: yes but no
<freemangordon> sure, but we don;t have voluke keys working, no?
<uvos> since the dbus calls for volume exist
<uvos> i think ill just implment them in mce
<uvos> so we can keep the keybaord disable
<freemangordon> but, how are those supposed to work if the input device is disabled?
<uvos> freemangordon: the xinput device is disabled
<uvos> not mces
<freemangordon> the same goes fot BT HF device
<uvos> mce uses kernel directly anyhow
<uvos> yes
<uvos> that would also work
<uvos> since mce gets all input including bt from kernel driectly
<freemangordon> wait, you're telling me we shall move volume buttons to mce?
<freemangordon> what about BT HF?
<uvos> bt devices create a input device on modern linux kernels
<uvos> so its the same as a keybaord
<uvos> yeah instead of tlock grabing all input
<freemangordon> yes, but how is mce supposed to know about it?
<uvos> it dosent have to
<freemangordon> sec
<uvos> instead of tklock grabbin all input and then sending volume via dbus
<uvos> mce can just do the same
<uvos> and get its input directly from kernal
<uvos> as is the case allreadt
<uvos> as is the case allready
<uvos> everything wokrs the same
<uvos> and we dont have to patch x
<uvos> to get pm working
<freemangordon> are you sure you'll be able to implement https://github.com/maemo-leste/osso-systemui-tklock/blob/master/gp-tklock.c#L227 in mce?
<Entitlement> freemangordon - [ osso-systemui-tklock/gp-tklock.c at master · maemo-leste/osso-systemui-tklock · ... ]
<uvos> yes
<freemangordon> ok
<uvos> its allmost implemented allready
<Wizzup> and this will work OK if a terminal wants to grab those buttons as well, right?
<Wizzup> e.g. osso-xterm
<Wizzup> no, not grab
<Wizzup> but listen to
<uvos> Wizzup: it wouild only be if the display is off
<Wizzup> ok
<uvos> Wizzup: like in tklock now
<uvos> Wizzup: so if display is on you just get XF86AudioLowerVolume via xinput
<uvos> like allways
<freemangordon> I don;t get it - how we both have the device enabled in kernel and disabled in X? I mean - we disable/close it in X to save power, but mce will hold it open, no?
<uvos> yes
<uvos> the problem is that x will enable the _DISPLAY_ if it gets any input
<freemangordon> so how it will enter powersaving mode then?
<uvos> the keyboard is open internaly to ther kenral anyhow
<freemangordon> ok, so the hack
<freemangordon> no, I prefer to fix X, we shall do it either ways because of glamor
<uvos> yeah but puting that code into mce has no downside
<uvos> so we might as well work with unpatched x too
<freemangordon> in leste?
<uvos> in everywhere
<freemangordon> we already work with patched X, because of modesetting bugs
<uvos> if you want to install hildon on arch linux or whatever why should it not work?
<freemangordon> I don;t care about everywhere, sorry
<uvos> it has no downside
<uvos> why do you want incopatabillity for no reason?
<freemangordon> on arch linux yo won't have systemui anyways
<uvos> but i will have x and mce...
<uvos> so mce can work right with stock x
<Wizzup> freemangordon: I am not sure if we can easily patch X for this
<parazyd> tbh it makes sense to me to tailor mce for interoperability
<freemangordon> Wizzup: why?
<uvos> you would have to define an extension
<uvos> lots of work
<freemangordon> or fix randr
<Wizzup> freemangordon: I think we'd have to introduce a new API or extension to X
RedW has quit [Ping timeout: 260 seconds]
<uvos> randr works as intended
<Wizzup> I'm quite happy with how it works currently tbh
<uvos> there is nothing to "fix"
<freemangordon> or whoever was unblanking the display
<uvos> works as inteded
<Wizzup> the problem is that with the drm api we can't work around X
<uvos> you would have to introduce a feature to turn it off
<Wizzup> we'd have to introduce some special X mode just to keep display off
<freemangordon> I think this is cheaper than start moving code from systemui to mce
<uvos> mce allready dose all of this
<uvos> its literaly 20 lines i have to add to mce
<uvos> just for the dbus call
<uvos> thats it
<freemangordon> and you'll implement systemui dbus interface in mce
<uvos> i dont think its a huge deal that mce implments a systemui funciton
<uvos> we can also reaname it mce
<uvos> its in a header anyhow
<uvos> so recompiled apps will pickup the new name
<freemangordon> ok, will think about that
<freemangordon> lets first fix vtklock bug
<uvos> btw also we could have vtklock running when the display is blanked (we need to stop it updating the clock)
<uvos> opening vtk is a major slowdown on turning on the display
<freemangordon> yeah, we need to redesign tklock
<uvos> the slowdown is why i use i3lock atm
<freemangordon> but lets do that once we are sure non-visual tklock is not needed
RedW has joined #maemo-leste
<freemangordon> actually we need it because of TKLOCK_ONEINPUT
<freemangordon> one of the most annoying things in android is that when you click on a dimmed display, you actually interact with the application that's active
<freemangordon> but you don;t really see what you're pressing
<uvos> mce dose this too
<uvos> it disables xinput on dim
<uvos> and enables it again after the first click
<freemangordon> it should not!
<uvos> i allready did when i started
<freemangordon> it is not mce's job to do that :(
<uvos> i dident add that
<uvos> i diddent add it
<freemangordon> didn't?
<uvos> no
<freemangordon> ok
<uvos> its in tklock.c
<uvos> or was
<uvos> now its in /modules/lock-tklock.c
<freemangordon> anyways, it is systemui's tklock job to do it
<freemangordon> uvos: so, I don;t get it - is this part of mce functionality or not? or it is in a module that is not enabled on leste?
<uvos> freemangordon: is part of mce funcitonalliy and has been so since forever
<uvos> only tklock.c is now a module
<uvos> but thats not a funcitonal change just a code structure one
<freemangordon> disabling xinput on dim was never a part of mce functionlaity
<uvos> right thats something else
<uvos> but mce disabled the keyboard via a kernel interface
<uvos> in onceklick mode
<uvos> that inteface is not mainline however
<freemangordon> ah, keyboard
<uvos> also ts
<freemangordon> but it should not be disabled as well
<freemangordon> on dim that is
<freemangordon> no, this is wrong
<uvos> maybe just ts
<uvos> and keyboard on off
<uvos> just look at the code
<freemangordon> those should be enabled so user to be able to undim by either TS or KBD or whatever input device
<uvos> yeah theres several states
<uvos> that disable different stuff
<uvos> i accutally removed this code because it cant work on mainline recently
<uvos> but thats not in leste
<freemangordon> this code? oneinput code?
<uvos> the part that tires to disable via kernel
<inky> uvos, i am so sorry. but.. i didn't test it well to find out it doesn't work for me. i saw that english works in 'pluma' and was happy but now i checked a couple of other keyboards and they don't work.
<inky> may be i installed the wrong package
<inky> deb https://maedevu.maemo.org/leste beowulf-devel main contrib non-free droid4
<Entitlement> inky - [ Directory Index - Maemo Leste ]
<inky> that's the line i added
<uvos> inky: you have to have a keymap that inlcudes the keys you want to type remember
<inky> and i saw that hildon-input-method was updated
<uvos> inky: so you have to create a xkb map that has all the d4 keys and your amenian ones assigned to something
<inky> during apt-get upgrade
<uvos> or switch to armeinan keyboard layout with xkb
<uvos> and sacrifice the hwkbd
<uvos> ill implment automatich switching at some point
<inky> i was thinking setxkbmap am is triggered automatically.
<uvos> no i havent done that part yet
<inky> when i change the layout on vkbd
<inky> ah.
<uvos> no not yet
<uvos> so you have to setxkbmap am or create a special map for yourself
<inky> what is the default droid4 map? so that i can return to it, if i type setxkbmap am
<uvos> idk just us i think
<inky> hm ok
<inky> let me try
<inky> yes nothing changed, so probably 'us' it is.
<inky> yes it works when i force xkbmap from console!
<inky> thank you!
<uvos> most of the work you did yourself :P
<freemangordon> ok, vtklock does only gtk_grab_add()
<freemangordon> that's why the bug
<uvos> freemangordon: whie working on vtk
<uvos> maybe also fix the lockslider being the wrong size in portrait
<freemangordon> I am in the VM, will see what can be done
diejuse1 has joined #maemo-leste
<Wizzup> 13:20 -!- diejuse1 [~diejuse@46.6.243.22] has quit [Quit: Leaving.]
<Wizzup> 13:22 < Wizzup> $ dpkg -S /usr/lib/hildon-control-panel/libcpdatetime.so
<Wizzup> 13:22 < Wizzup> applet-datetime: /usr/lib/hildon-control-panel/libcpdatetime.so
random_yanek has quit [Ping timeout: 250 seconds]
random_yanek has joined #maemo-leste
belcher has quit [Ping timeout: 240 seconds]
belcher has joined #maemo-leste
<diejuse1> Wizzup: thanks, dpkg -S /usr/lib/hildon-control-panel/libcpdatetime.so not worked but apt install applet-datetime does
<Wizzup> diejuse1: dpkg -S tells you what package a file belongs to
<diejuse1> ah ok
<diejuse1> I need to learn a lot more about Linux commands. I'm on it.
<Wizzup> still waiting on the documentation :-p
<diejuse1> haha, you will see it, some patience
xmn has joined #maemo-leste
diejuse11 has joined #maemo-leste
diejuse1 has quit [Ping timeout: 246 seconds]
diejuse11 has quit [Ping timeout: 240 seconds]
R0b0t1 has quit [Ping timeout: 246 seconds]
R0b0t1 has joined #maemo-leste
<Wizzup> is there an easy way to list all our extras pkgs here? https://maedevu.maemo.org/pkgweb/
<Entitlement> Wizzup - [ Maemo Package Index ]
xmn has quit [Quit: xmn]
xmn has joined #maemo-leste
_whitelogger has joined #maemo-leste
_whitelogger has joined #maemo-leste
cato`[m] has left #maemo-leste ["User left"]
pere has quit [Ping timeout: 260 seconds]
pagurus has joined #maemo-leste
halftux has quit [Quit: leaving]
diejuse1 has joined #maemo-leste
jonsger has joined #maemo-leste
<kek> MerlijnWajer created a repository: https://github.com/maemo-leste-extras/modrana
<kek> MerlijnWajer edited a repository: https://github.com/maemo-leste-extras/modrana
<uvos> are you building the Qt Quick version or gtk version?
<uvos> btw we should support qlocation on liblocation in our qt version
<Wizzup> gtk currently
<Wizzup> the qt version gave me trouble
<uvos> or if we plan to switch to geoclue then it would work atomaticly
<Wizzup> feel free to contribute/add :)
<uvos> we need to decide on how gps stack shall look first...
<uvos> liblocation -> libgeoclue looks like a easy shim btw
<Wizzup> I mean, modrana uses liblocation
<uvos> sure
<Wizzup> this is the n900-branch from modrana's github
<uvos> just saying that qlocation is a thing
<Wizzup> right, but it shouldn't use it in the gtk build at least
<Wizzup> point being: yes, perhaps there is more to do in location (there is), but that shouldn't stop a gtk build of this to extras
<Wizzup> I haven't looked much at geoclue yet
<Wizzup> uvos: but yeah, I forgot about qlocation
<Wizzup> it'll be close to impossible to enforce location on/off if we have all these different frameworks doing their own thing...
<uvos> Wizzup: no its ok
<uvos> Wizzup: i did a survay and everything supports/uses geoclue
<uvos> and geoclue can tell us its active
<Wizzup> ok (sry, mtg atm, will reply later)
<uvos> so it looks like we mostly dont even have to support gpsd at all
<uvos> and we can lock the soccet behind a user that geclue starts as
<uvos> arch dose this
<uvos> and all or at least almost all desktop apps support libgeoclue
<uvos> or its dbus interface
<uvos> so if we implement liblocation on it everything will just work
<uvos> what is also neat is we gain network and ip location fallbacks
<uvos> and get bearing information from the the compass while stationary where available
<uvos> for free
<uvos> and geoclue also supports gps active notification
<uvos> so everything mostly just falls into place if we use it
<Wizzup> uvos: it sounds good
pere has joined #maemo-leste
jonsger has quit [Remote host closed the connection]
jonsger has joined #maemo-leste
jonsger has quit [Quit: jonsger]
jonsger has joined #maemo-leste
jonsger has left #maemo-leste [#maemo-leste]
<Wizzup> modrana doesn't work, but it works in the vm, weird
<Wizzup> oh, they important files get excluded for the 'fedora' path
pere has quit [Ping timeout: 265 seconds]
<Entitlement> freemangordon - [ IRC Council resolution: On Recent freenode Events ]
<freemangordon> I think we shall follow
<freemangordon> also, see doc's stance on #maemo
<Wizzup> well, we have 81 nicks now, let's see if we can get back to that number in a month or two over there ;-)
<uvos> dont worry 69 of those are clort alts anyhow
<freemangordon> Wizzup: seems everyone is moving, we shall at least change the wiki and add a notice int the topic
<freemangordon> and doing conversations on libera
<freemangordon> and asking active users to join there. active == asking questions
<Wizzup> uvos: lol
<Wizzup> freemangordon: ok
<freemangordon> hmm?
<freemangordon> I have no clue of irc
<Wizzup> oh, ok
<Wizzup> I'll do it in a bit then
<Wizzup> topic change etc
<freemangordon> well, it is not that urgent I guess
<Wizzup> sicelo: modrana is in -extras
<Wizzup> the gtk version
<Wizzup> uvos: any clue how A-GPS will work with geoclue?
<Wizzup> we'll need device specific stuff I think
<Wizzup> (I am sure we do)
<uvos> no sorry
<uvos> i dont thinks it deals with that at all
<Wizzup> those kind of things will get harder then
<uvos> i gues we could just use cron and a script
<uvos> since agps is just periodicly updateing the almenac
<uvos> or rather anacron
<freemangordon> we shall do that on demand
<freemangordon> not on cron
<uvos> maybe gpsd hase sutch facilitys
<uvos> idk
<uvos> freemangordon: sure would be better
<Wizzup> uvos: no, gpsd does not do A-GPS
<Wizzup> we were planning to do in location-daemon hooks
<Wizzup> but I guess that would not exist with geoclue
<uvos> Wizzup: maybe geclue has somehting like that idk
<freemangordon> Wizzup: wait, isn;t AGPS just downloading the almanac from the operator?
<uvos> freemangordon: yes
<uvos> but you have to upload it to the modem
<freemangordon> yeah
<freemangordon> ofc
<uvos> whitch is device dependant
<freemangordon> mhm
<uvos> Wizzup: if not we can just have something that uses the status notifier api of goclue to update the almenac
<uvos> if some other conditions are also met
<freemangordon> anyway, going to have some sleep, night
<uvos> (like almenac age)
pere has joined #maemo-leste
<uvos> Wizzup: looks like sailfishos has dealt this this problem
<Entitlement> uvos - [ Positioning - SailfishOS Documentation ]
<uvos> and also uses geoclue btw
mardy has quit [Quit: WeeChat 2.8]
<Entitlement> uvos - [ GitHub - mer-hybris/geoclue-providers-mlsdb ]
<uvos> looks like they wrote a plugin
<uvos> we can do the same
<Wizzup> uvos: that is not A-GPS though
<Wizzup> but yeah, that's definitely very useful
<uvos> i just read this using Mozilla Location Service to provide assisted-GPS position updates:
<uvos> maybe by assisted they dont mean agps idk
<Wizzup> well AGPS the way I mean it is feeding the data back to the modem as discussed earlier here
<Wizzup> so that is can more quickly get a accurate fix
<uvos> yeah i know
<uvos> i do to
<uvos> i was just assuming that plugin gets a almenac from moz
<uvos> (by the desciption)
<uvos> but idk i dident read the code
<uvos> we can also survay what plamo and phosh do
<uvos> since they also use geoclue
<uvos> point is everyone uses it so someone must have solved this problem :P
<uvos> i would hope
R0b0t1 has quit [Remote host closed the connection]
R0b0t1 has joined #maemo-leste
<Wizzup> uvos: I don't automatically assume that people solve the problem and solve it well, but I agree that geoclue might be a good thing to use
<uvos> im also really not hugely adverse to a cron job
<uvos> you only have to update the almeac once every 2 weaks so...
peetah has left #maemo-leste [#maemo-leste]
<uvos> * once every 1 weak it seams
<uvos> still not a huge burden if the device dose it even if gps is not used
<Wizzup> I don't think cron is sensible
<Wizzup> as in, the device needs to be connected to internet, etc etc
<uvos> well we could have something like we do for ntp
<uvos> just runn some script on network connect
<Wizzup> yes, probably integrated in the location framework ;-)
<uvos> if the almenac is >7 days old
<uvos> upate it
<Wizzup> yeah it's possible, but not on metered connections I'd say
<Wizzup> also: devuan plymouth doesn't do openrc, it requires systemd, so it's
<Wizzup> just not available
<Wizzup> but gentoo does plymouth and openrc just fine
<Wizzup> *sigh* :)
<uvos> its pretty small
<Entitlement> Wizzup - [ GitHub - Kangie/plymouth-openrc-plugin: Plymouth plugin for OpenRC, currently ma... ]
<uvos> i dont think 60k on a metered connection every week is a big deal either
<Wizzup> uvos: fair
diejuse1 has quit [Ping timeout: 246 seconds]
<uvos> and when im off wifi for a week thats exactly the time i want my gps to damn well work..
<Wizzup> uvos: mhm
<Wizzup> I mean the almanacs really shouldn't change that often though right?
<Wizzup> but yeah, sure
<uvos> in meo?
<uvos> sure
<uvos> they do
diejuse1 has joined #maemo-leste
cockroach has joined #maemo-leste
ceene has quit [Ping timeout: 250 seconds]
R0b0t1 has quit [Ping timeout: 260 seconds]
uvos has quit [Ping timeout: 252 seconds]