<Wizzup>
uvos: nice work @ full screen, will try to test it all today
<uvos>
btw i noticed another problem while testing for this
<uvos>
tklock dosent XGrabKeyboard()
<uvos>
so .... it fails as a lock screen
<uvos>
any applicaiton that uses XGrabKey() to register a shortcut will work dispite the lockscreen
<uvos>
and any applciation that XSetInputFocus() will also get keyboard input despite the lockscreen
<uvos>
also since keyboard grab isent held by tklock any window that did register a grab (like a context menu) will end up locking the input focus away from tklock, witch is wierd and also means your interacting with the contex menu though the lockscreen
<Wizzup>
that sounds buggy
<uvos>
i think this is on purpose maybe
<uvos>
so that applications can xgrabkey for music shortcuts and the like
<uvos>
and vol up down
<Wizzup>
oh, yeah...
<uvos>
but thats... not really how a lockscreen on x11 works
<uvos>
not sure how to solve this really
<uvos>
but i need to at least stop hildon form using it shortcuts with tklock active
<Wizzup>
the ts buttons?
<uvos>
rn you can just navigate away from tklock via the d4 buttons
<Wizzup>
right
<uvos>
and ctrl-backspace
<uvos>
i never noticed this because i use i3lock
<uvos>
:P
<Wizzup>
ah, yeah, I don't see it with control+backspace, but the home buttom does that
<Wizzup>
and the arrow just kills it
<uvos>
ctrl+backspace is nolong bound on d4
<uvos>
yeah arrow just killing it is pretty bad
<uvos>
since mce then gets out of sync with systemui
<Wizzup>
I don't know what mechanism within X would even make sense for this
<Wizzup>
but iirc we discussed this before
<Wizzup>
like half a year ago or so, wrt volume control
<uvos>
XGrabKeyboard() + passthough for whatever we like
<uvos>
using synthetic events
<siceloa>
why was it necessary for ctrl-backspace to be unbound on droid 4, if i may ask?
<uvos>
siceloa: i made the shortcuts bindable to different whatever keys via an .ini file, however rn. you can only bind one shortcut per action
<uvos>
siceloa: i made the decission that the ctrl-backspace behavior is more usefull on the d4 home button
<siceloa>
i see
<uvos>
if there is great popular demand i can just duplicate the action btw.
<uvos>
also this is device specific n900 retains ctrl-backspace
<uvos>
and pp has it on vol down
inky has quit [Ping timeout: 240 seconds]
inky has joined #maemo-leste
Pali has joined #maemo-leste
jonsger has joined #maemo-leste
inky has quit [Ping timeout: 252 seconds]
inky has joined #maemo-leste
<siceloa>
So how will pp do an actual vol down when the key is used in this way? 🤔
<uvos>
siceloa: they dont rn
<siceloa>
Yes I know the volume applet isn't working currently.
<Wizzup>
siceloa: no, but we also don't have volapplet working yet
<uvos>
yeah idk what is best for pp
<uvos>
some method to raise the vkb is needed
<uvos>
so i have to assign that somewhere
<uvos>
so thats one vol button
<uvos>
and then the other one i might as well assign aswel
jonsger has quit [Ping timeout: 240 seconds]
<siceloa>
so, droid4-pm mentions to unload droid4 touchscreen driver when screen is blanked. are we actually doing that in leste?
<uvos>
siceloa: no and its not nesecary at all
<uvos>
mce simply ensures that everybode closes the input device on screen blank
<siceloa>
alright. makes sense
sunshavi has quit [Ping timeout: 240 seconds]
inky has quit [Ping timeout: 268 seconds]
jonsger has joined #maemo-leste
<freemangordon>
I don;t really like reassigning volume buttons functionlaity
<freemangordon>
uvos: you may add an entry in power key menu
<freemangordon>
part of its functionality is calling dbus, you just need to add config file with interface and function (iirc)
uvos has quit [Quit: Konversation terminated!]
uvos has joined #maemo-leste
<uvos>
freemangordon: idk that sounds like terribe ux
<uvos>
freemangordon: since you need to open/close the vkb very often
<uvos>
freemangordon: but yeah we should have both as an option
<uvos>
freemangordon: so that either you need to ajust the volume only in the staus menu
<uvos>
freemangordon: or you can only open vkb in power menu
<uvos>
freemangordon: likey ideal (but hard to implement) would be adding a button in the pannel next to the left hildon button that raises vkb
<uvos>
but only on ts only phones with no extra keys
<uvos>
(like all modern ones)
pagurus has joined #maemo-leste
<freemangordon>
uvos: a gesture?
<uvos>
sure that would work
<freemangordon>
hmm, didn't we already agree on the gesture?
<Entitlement>
siceloa - [ Pinephone is the perfect reason to fix bad code. - Konrad Dybcio ]
<uvos>
not that i remember
<freemangordon>
I have some vague memories
<uvos>
ok
<freemangordon>
but anyway
<freemangordon>
still, I think this is the best option and is device independent
<siceloa>
+1
<uvos>
i like haveing it on a key where one is available (like bionic)
<uvos>
but sure a device independant additional method is good to
<uvos>
anyhow i think assinging it to vol-up on pp is fine untill we have volume control
<freemangordon>
yeah, if we can dedicate a key to it is good to have
<freemangordon>
ok
<freemangordon>
As long as it is a temporary solution I am fine
<horseshoecrab>
hi, i have a question as a new user: is there supposed to be a gui sip client available? (disclaimer: i am extremely happy with my maemo-leste experience so far, i do understand it is alpha and you guys have already exceeded my expectations for the distro in terms of the bizarre use that i put my n900 to, so please do NOT take this is complaint, nagging or criticism in any form!) ?
<uvos>
horseshoecrab: no
<uvos>
horseshoecrab: but you can use anything from debian
<horseshoecrab>
thanks.
<uvos>
horseshoecrab: with varring levels of ui
<uvos>
dekstop uis on the phone are a bit though ofc
<horseshoecrab>
yeah i don't think i want one badly enough.
<horseshoecrab>
its just that i think i saw some screenshots that included it and wondered why my install was lacking.
<horseshoecrab>
but its not a big problem in any way.
<horseshoecrab>
as an aside, i think i also asked a question a while back regarding resolv.conf. i think at the time it could only use google resolvers.
<horseshoecrab>
i dunno if ive managed to freak something or you guys have fixed it but that seems to be working now too.
<horseshoecrab>
:)
<uvos>
this is fixed (in devel)
<siceloa>
this just got solved :)
<uvos>
yeah parazyd fixed it
<horseshoecrab>
top man
<horseshoecrab>
:)
<uvos>
btw regarding sip. its not sip per say but you can use telegram-desktop to place calls over ip, with perfect phone ui.
<horseshoecrab>
its no problem.
<uvos>
n900 also might not have enough ram
<horseshoecrab>
i mainly just use my n900 as a little bedside music player (with mplayer of all things) and i run an irc bot on it.
<uvos>
cool
<horseshoecrab>
and its good to have an up to date kernel
<siceloa>
i had some success with SIP via empathy on the N900
<horseshoecrab>
ssl etc. thanks to devuan
<horseshoecrab>
and the commandline stuff that works nicely with the low ram
<uvos>
well n900 is pretty behind kernel wise sadly
<horseshoecrab>
anything else i take as cherry on the cake
<uvos>
not nearly as mutch as freemantle ofc :P
<horseshoecrab>
uvos: i have a couple of nslu2s here and an old ppc mac
<horseshoecrab>
compared to those this thing is very up to date.
<horseshoecrab>
and considering that my usual distro of choice is debian stable... ;)
<horseshoecrab>
i had it dual booting some sort of frankendebian with a 4 series kernel that i had no idea how to update without losing more hair.
<horseshoecrab>
you guys have solved that very neatly for the short to medium term at least, and for that i am extremely grateful.
<Wizzup>
siceloa: :)
<siceloa>
I read that, and again remembered that Leste blog post
<Wizzup>
which one in particular?
<sicelo>
the last one
<sicelo>
"Lacking phone calls might seem ridiculous to some, but there are many aspects that matter about a mobile operating system, and working phone calls without any sense of power management ... also make a device hardly usable"
<Wizzup>
right, yeah.
inky has joined #maemo-leste
uvos_ has joined #maemo-leste
<uvos_>
we have had pm for a while now, so phone ui tomorrow right?
<uvos_>
right!?
<parazyd>
That's part of the "good news" :p
<uvos_>
hehe
uvos_ has quit [Quit: uvos_]
<sicelo>
my droid 4 seems to 'forget' to enter charging mode now. i wonder why
<sicelo>
i see this in Alpine, running 5.12.0-rc2, and also in Leste -devel
<sicelo>
i started thinking it could be bad cable or port, but it's fine in android. anyone observed this on their droid4?
Entitlement has quit [Remote host closed the connection]
Entitlement has joined #maemo-leste
<uvos>
sicelo: there was a missing patch
Entitlement has quit [Ping timeout: 252 seconds]
Entitlement has joined #maemo-leste
<sicelo>
ah ok. at least if it's a known issue. for a moment was fretting that my usb port (in droid4) is developing issues
<uvos>
you need "[PATCH 5/5] power: supply: cpcap-charger: Add usleep to cpcap charger to avoid usb plug bounce"
<uvos>
if you dont have it allready
<uvos>
its in -next
<siceloa>
thanks. but, how about devel? i observed this in Leste devel too (with whatever kernel it has - i have two uSD cards - one for Leste and one for playing with wayland, currently pmos)
<uvos>
i dont think it has made its way to leste
<uvos>
unless tony added it to his pending branch
<uvos>
before parazyd recently rebuilt the kernel
<uvos>
it was in there before
<uvos>
but went missing with 5.10
<uvos>
iirc
<parazyd>
Yeah it's not in our branches
<parazyd>
afaict at least
<parazyd>
Want me to add it to debian/patches?
<uvos>
parazyd: if you like afaict for me at least its only needed @ >500ma so its not hugely important
<parazyd>
500 is set as the default current limit, no?
<parazyd>
Or is this about the max a charger can provide?
<uvos>
yeah is default
<uvos>
but i gues if your contacts are dirty
jonsger has quit [Ping timeout: 246 seconds]
<uvos>
or if your cable is long
<uvos>
it might trip at 500 to
<parazyd>
Right
<siceloa>
a charger, by definition, should provide >500mA. you get =<500mA from USB port. so i'm not sure i follow the logic ...
<uvos>
d4 currently dosent detect anything
<uvos>
it just takes 500mA
<uvos>
or whatever you set in sysfs
<siceloa>
heh
<uvos>
so it breaks procoll everywhere
<uvos>
on a usbport you are only allowed 40uA iirc
<uvos>
and on a charger you are guarenteed 500mA
<uvos>
without negotiating high power mode
<uvos>
so it breaks spec, differing ports/chargers react differently
<siceloa>
anyway, my point is - the device does not charge - at least it charges 3 times out of 5. i think that's bad, so if that patch fixes it, then i would say it's important that it comes to devel