Pali has quit [Read error: Connection reset by peer]
Pali has joined #maemo-leste
Pali has quit [Ping timeout: 256 seconds]
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
macros__ has joined #maemo-leste
macros_ has quit [Ping timeout: 250 seconds]
mardy has joined #maemo-leste
<freemangordon>
alarm volume is not set, it is always @ max
<freemangordon>
also, native device orientation can but get from xrandr, we don;t need some device specific config
<freemangordon>
*can be
<freemangordon>
and again, I prefer to discuss architecture decision before those being coded
<freemangordon>
*decisions
<freemangordon>
I am not going to deduce about behaviour based on code
<freemangordon>
Wizzup: I would really appreciate next time to at least give me a chance to have a look @ PR to code I am author and maintainer of
freemangordon has quit [*.net *.split]
inky has quit [*.net *.split]
mp107 has quit [*.net *.split]
bencoh has quit [*.net *.split]
juiceme has quit [*.net *.split]
yanu has quit [*.net *.split]
ikmaak has quit [*.net *.split]
blasty has quit [*.net *.split]
lel has quit [*.net *.split]
amk has quit [*.net *.split]
Langoor has quit [*.net *.split]
sixwheeledbeast has quit [*.net *.split]
Danct12 has quit [Ping timeout: 250 seconds]
Danct12 has joined #maemo-leste
freemangordon has joined #maemo-leste
inky has joined #maemo-leste
mp107 has joined #maemo-leste
sixwheeledbeast has joined #maemo-leste
bencoh has joined #maemo-leste
juiceme has joined #maemo-leste
blasty has joined #maemo-leste
yanu has joined #maemo-leste
lel has joined #maemo-leste
amk has joined #maemo-leste
ikmaak has joined #maemo-leste
Langoor has joined #maemo-leste
xmn has quit [Ping timeout: 250 seconds]
mrkrisprolls has quit [Ping timeout: 250 seconds]
mrkrisprolls has joined #maemo-leste
Pali has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
macros__ has quit [Quit: Konversation terminated!]
macros_ has joined #maemo-leste
_uvos_ has joined #maemo-leste
<Wizzup>
freemangordon: check
<_uvos_>
fremangordon: yes we do what is "native" for the orientation of the volume buttons
<_uvos_>
is totaly independant of the scann direction of the display
<_uvos_>
of course the alarm volume is set
<_uvos_>
just because the proparty isent user faceing in the ui (another large deficancy in fremantle) dosent make it not set
<_uvos_>
irc.txt broke again btw
<Wizzup>
we also have the other logs
<Wizzup>
let me fix it again though
<_uvos_>
sure
<Wizzup>
irc.txt is just running 'ii'
<Wizzup>
I guess it doesn't handle some stuff well
<_uvos_>
i just find the ui of whitequark very bad
<_uvos_>
i mean i have to know todays date to find the latest messages
lel has quit [Remote host closed the connection]
<_uvos_>
also grep
lel has joined #maemo-leste
<Wizzup>
should be ok again
<_uvos_>
test....
<_uvos_>
no
<Wizzup>
let's give if a few mins just in case it's some cache/buffer thing
uvos has joined #maemo-leste
<freemangordon>
uvos: volume buttons *should not* depend on stuff like *native* orientation, bot on top application orientation
<freemangordon>
please, do not try to oversmart Nokia in terms of UX
<uvos>
freemangordon: yes its totaly sane that the volume buttons, when the display are off, are, totally unkown and unkoable to the user, in a random orientation
<uvos>
this is about what orientation they are in while the display is off
<freemangordon>
still, the bahaviour shall be cosistent
<uvos>
volume up
<freemangordon>
imagine if you lock your screen with media player in portrait
<uvos>
is to be up on the device
<uvos>
at all times
<uvos>
if the display is off
<uvos>
period
<freemangordon>
no
<freemangordon>
sorry
<freemangordon>
this is not consistent
<uvos>
so what you want is:
<uvos>
if i lock the device while its in portrait mode the orientation of the volume buttons is one way, if i lock them when the device is in landscape the volume buttons are in another
<freemangordon>
mhm
<uvos>
and when i go to change the volume i must somehow remember the state the device was in
<freemangordon>
and, it is not about what *I* want
<uvos>
30 minutes ago
<uvos>
this is stupidity
<freemangordon>
applet is already registered to mce events
<freemangordon>
so it is about one integer damamit!
<uvos>
WHILE THE DISPLAY IS OFF
<uvos>
there is no rotating anything in this state
<freemangordon>
yes, while the display is off
<uvos>
no
<uvos>
mce will not and cann not
<uvos>
have the accel on at all times
_uvos_ has quit [Ping timeout: 256 seconds]
<uvos>
and even then
<freemangordon>
you don;t follow
<uvos>
its not like the accel is some magic bullet
<uvos>
im sorry you are wrong
<freemangordon>
lemme explain
<uvos>
and the behavior of the original code wasent like that either
<uvos>
and your intended behavior
<uvos>
is more than the hight of folly
<freemangordon>
could you listen for a while?
<freemangordon>
?
<freemangordon>
I assume yes, so:
<freemangordon>
it is not about what orientation is currently the device in (with display off)
<freemangordon>
it is about what orientation device was before display went off
<freemangordon>
*the last* orientation in terms of what h-d did last
<freemangordon>
not what accel said
<uvos>
yes
<uvos>
and that is stupid
<freemangordon>
says who?
<uvos>
to the highest degree
<uvos>
and not what the code ever did
<freemangordon>
I give up
<freemangordon>
this is not a discussion
<uvos>
this forces you to know
<Wizzup>
freemangordon: how does this work on fremantle?
<Wizzup>
I don't think it works like this on fremantle
<uvos>
what orientation the device was in when the display whent off
<uvos>
this is VERY bad
<Wizzup>
at least not on my n900 - I just tried
<uvos>
the user is not psychic
<freemangordon>
how did you try?
<Wizzup>
freemangordon: I set volume off, help it on portrait, locked device, tried to change volume
<Wizzup>
by pressing the top (in landscape left) volume button a few times
<Wizzup>
and nothing happened
<Wizzup>
s/help/held/
<Wizzup>
I did see h-d rotate to portrait as well
<Wizzup>
I am on cssu
<Wizzup>
in general I really think that these smalls *details* like do we keep track of orientation and change volume buttons based on orientation are things worth discussing, but it makes much more sense to have a strong discussion about them when we have bigger things in place, until then I think we have bigger things to deal with imho
<freemangordon>
and for sure on the device in front of me it works like that
<freemangordon>
buttons got swapped
<Wizzup>
well imho it is a bit questionable as well for various reasons, but I don't have a strong opinion on it either way, I rarely change the volume when the screen is locked because I don't know what it will do
<humpelstilzchen[>
Wizzup: Thx, did not try the new package yet, but should have fixed it, since I compiled & tested exactly this config
<Wizzup>
combine that with the fact that tklock doesn't typically render in portrait mode, and it's just confusing
<Wizzup>
humpelstilzchen[: ok, let me know if you need help testing it, not sure if you used the -devel repos before
<freemangordon>
1. fremantle UX does it like that. 2. it might not be to the taste of every user, well, as humpelstilzchen[ said, make it config option *without breaking default UX*
<uvos>
fremantle "UX" (realy the hmi) is _terrible_ quite often
<uvos>
its not some gospel
<uvos>
also when locked
<uvos>
the widget allways reads landscape
<uvos>
might be some ddx thing
<uvos>
but thats how it works
<uvos>
"I rarely change the volume when the screen is locked because I don't know what it will do"
<uvos>
right thats the problem
<Wizzup>
freemangordon: I think is we set the value for n900 in leste-config-n900 it should not break the default ux?
<freemangordon>
how is n900 related here?
<uvos>
with freemangordon's inteded behavior the user has to be Psychic
<uvos>
there is not telling how the volume keys will react before pressing them
<Wizzup>
I wouldn't mind having a psychic connection to my bt :)
<Wizzup>
for my n900*
<Wizzup>
to my n900*
<Wizzup>
ugh
<freemangordon>
have to attend work mtg, ttyl
<Wizzup>
freemangordon: afaik there is an option, swap_on_rotate
<uvos>
no
<uvos>
turning that off
<uvos>
makes it never swap at all
<uvos>
ie also not when the display is on
<uvos>
like is really the best "ux"
<uvos>
because it dosent break musscel memory
<Wizzup>
I guess my question is, can we change the ini to get default fremantle ux or is the code different in such a way that this is no longer possible
<Wizzup>
the PR I looked at didn't seem to touch that code other than through the config var
<uvos>
that is correct
<uvos>
turning it on again
<uvos>
makes it like fremantle
<uvos>
however thats not how fremangordon wants it to work
<uvos>
maybe because the widget reads the wrong orientation while off
<uvos>
but it dose the same in non cssu fremantle here
<Wizzup>
right, it sounds like it works for him on fremantle, so maybe it's a ddx/lockscreen thing
<Wizzup>
i.e. that bug is elsewhere
<uvos>
i also think that in this case fremantle "ux" if that is the intention (not convinced considering how it behaves in non cssu) is just bad
<uvos>
and we should not be held to it
<Wizzup>
yeah, I don't care so much about this so not sure what to make of it, I'd rather focus on other parts, so no strong opinion here, I'd say pick a default and just move on, if users complain about one way over another they'll know where to find us
<uvos>
(really tklock should just not rotate itself)
<uvos>
same problem with applications that rotate themselves
<uvos>
(ie brainparty and cloudgps)
<uvos>
again applicaitons roating themselves are broken
<uvos>
they should never do that
<Wizzup>
humpelstilzchen[: yes
<Wizzup>
uvos: maybe we should make two packages: hildon-config-nokia and hildon-config-<somethingelse>
<Wizzup>
nokia mimics fremantle
<Wizzup>
for all these things, h-d config, volume applet config
<humpelstilzchen[>
Wizzup: kernel works, but one strange thing, apt-cache policy told me the previous package was newer pine64-linux_5.15.0-1+2m7.2, latest in beowulf-devel is 5.15.0-1+2m7.1
<humpelstilzchen[>
so I told apt to downgrade
<humpelstilzchen[>
uname says the kernel is from yesterday
<Wizzup>
uvos: and it doesn't configure the rest of the packages
<Wizzup>
the only way I was able to work around it without rebooting was renaming the init script
<huckg>
Sorry I brought up 2 issues at once.
<uvos>
just stop the script
<Wizzup>
I am pushing a leste-config change now with /usr/sbin/policy-rc.d
<uvos>
then
<Wizzup>
uvos: I did this, it won't stop, the flock thing just hangs
<uvos>
Wizzup: so?
<uvos>
/etc/init.d/hildon-desktop reset
<Wizzup>
it is zap, but it still doesn't help
<uvos>
ok
<Wizzup>
for me at least
<Wizzup>
I pushed a basic policy-rc.d to -devel
<Wizzup>
if you have suggestions for a dirname where it can read additional blacklists lmk
<Wizzup>
/etc/policy-rc.d seemed awkward
macros_ has quit [Ping timeout: 256 seconds]
<huckg>
uvos: when you suggested /etc/init.d/hildon-desktop reset did you mean restart?
<Wizzup>
huckg: are you on -devel?
<huckg>
no
<Wizzup>
ok
<Wizzup>
huckg: so my temporary workaround was mv /etc/init.d/hildon-desktop /etc/init.d/hildon-desktop_
<Wizzup>
and then move it back, but I'm pushing a fix to -devel for this stuff
<huckg>
Wizzup: thanks, that worked. There was this during the upgrade: *** OMINOUS WARNING ***: /usr/share/alsa/ucm2/Mapphone_Audio/HiFi.conf is not li
<huckg>
nked to either HiFi.conf.leste or HiFi.conf.leste-orig
<uvos>
huckg: right you chainged it
<huckg>
maybe that is because I previously edited HiFi.conf
<uvos>
its not a problem rn
<uvos>
but it will be if we ever change it
<uvos>
to add new profiles etc
<Wizzup>
hm I just realised we do have a non-functioning special keys keyboard on stable now
<uvos>
i dont think it worked in stable before either
<uvos>
pretty sure it broke unoticed quite some time before the last promote
System_Error has quit [Ping timeout: 276 seconds]
<Wizzup>
on the n900 this means you cannot type the pipe symbol
<uvos>
yeah
<Wizzup>
'|'
<uvos>
porblem is i reverted him quite far
<uvos>
and it made no difference
<uvos>
so im not sure what cuased it
<Wizzup>
does the code to act on these buttons get triggered at all, and maybe the svc showing just doesn't work?
<Wizzup>
I have no idea what exactly broke
<uvos>
no it dosent
<uvos>
i never gets the signal
<uvos>
to open
<Wizzup>
ok, so issuing the request over dbus still works?
<uvos>
thats not how it works
<uvos>
it uses xatoms
<uvos>
to transfer all keybord input
<uvos>
into gtk2 windows
<uvos>
back to him
<uvos>
(yes this is nuts :P)
<uvos>
and then him acts on that
<uvos>
theoreticly
<Wizzup>
btw side note if you revert hildon-input-method-framework stuff you also need to rebuild other pkgs iirc
<uvos>
i reverted him
<uvos>
theres only on change to himf
<uvos>
and dident look related at all
<uvos>
but you could try that
<Wizzup>
right the enter key unredirect
<Wizzup>
even that is too old, I am pretty sure it did work before
<uvos>
but raising it on d4 did work at some point
<uvos>
for sure
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
huckg has quit [Quit: Client closed]
_inky has quit [Read error: Connection reset by peer]
_inky has joined #maemo-leste
huckg has joined #maemo-leste
<freemangordon>
uvos: never seen it working on d4
<freemangordon>
but it worked on n900
<freemangordon>
so, I think the bisect shall be done by testing on n900, if you plan to do so
<Wizzup>
I can try to build this on my n900
<freemangordon>
Wizzup: actually there is '|' even in normal vkb
<freemangordon>
you have to select numeric one and press shift
<freemangordon>
Wizzup: don't waste your time, I'll look at it during the weekend
<Wizzup>
freemangordon: ok, ty!
<Wizzup>
another thing I noticed is that we specify layout to us in xorg conf
<Wizzup>
not sure if we need that, since iirc we have /etc/default/keyboard for that
<Wizzup>
huckg: is the new 2d/3d stuff working for you on bionic? it should be faster
<uvos>
Wizzup: did you figure out what to do about libsdl2?
<huckg>
Wizzup: yes, tried out qtbrowser and it seemed smoother.
<uvos>
qtbrowser is unfotionatly not accelerated at all
<uvos>
so it only benefits slightly
<freemangordon>
uvos: still, rendering should be faster because of the blit is faster
<uvos>
right
<uvos>
and it is
<freemangordon>
yeah, slightly
<uvos>
but not to the extent of ff for instance
<freemangordon>
yeah
<freemangordon>
hmm, are you sure FF is accelerated?
huckg100 has joined #maemo-leste
huckg100 has quit [Client Quit]
<freemangordon>
I think it is not, at least according to about:support
<uvos>
it should be
<uvos>
ok
<uvos>
hmm
<freemangordon>
most-probably it is not, because PVR is not whitelisted
<freemangordon>
not 100%sure though, lemme check
huckg63 has joined #maemo-leste
huckg63 has quit [Client Quit]
<uvos>
it gets unrealistic performance on videos tho
<freemangordon>
uvos: BTW, what is this ddx crash? something with VTs
<uvos>
if not accelerated
<uvos>
freemangordon: switch vts
<uvos>
and then back to the vt with x
<freemangordon>
how>
<uvos>
crash
<uvos>
every time
<freemangordon>
how?
<uvos>
ssh, chvt
<freemangordon>
chvt 0?
<uvos>
sure
<freemangordon>
chvt 7?
<uvos>
or plug in a keyboard
<uvos>
yes
<freemangordon>
ok
huckg has quit [Ping timeout: 256 seconds]
<freemangordon>
uvos: seems firefox wants opengl
<freemangordon>
not gles
<uvos>
for webgl
<freemangordon>
not only
<freemangordon>
for rendering too
<freemangordon>
check in about:support:
<freemangordon>
HW_COMPOSITING etc
<uvos>
i have a hard time gorking what this means
<uvos>
it sais available by default
<freemangordon>
but disabled by platform :)
<freemangordon>
I am trying to enable
<freemangordon>
yeah, it searches for opengl
<uvos>
its interesting that it manages mutch better performance in yt than mpv dose in native videos
<uvos>
this allone made me assume it must be accelerated
<freemangordon>
open about:config
<freemangordon>
and set layers.accelerated.draw-fps to true
<freemangordon>
and force-enabled to true
<freemangordon>
restart FF and you'll see that it complains for missing opengl
<uvos>
yeah
<uvos>
also it scrolls at 35fps
<freemangordon>
which site?
<uvos>
just my homepage
<uvos>
(simple)
<uvos>
also irc.txt
<uvos>
bbc is like 25 ish
<uvos>
it suprises me it manages that mutch really
<freemangordon>
maybe you did some tweaks, as here it scrolls with ~25
<freemangordon>
yeah, same then
<freemangordon>
well, it should be way faster, but FF become so bloated nowadays
<freemangordon>
uvos: do you plan to look at this panel power-on bug?
huckg has joined #maemo-leste
<uvos>
not immiatly
<freemangordon>
ok
<uvos>
i find it fairly low priority
<uvos>
since it mostly dosent hurt anyone
<freemangordon>
correct, but after I fix the crash and enable TE, this will be the only remaining bug and if we fix it as well, we can label DDX stable
<freemangordon>
DDX/rendering
<uvos>
i dont think it has anything to do with ddx
<uvos>
ok
<freemangordon>
yeah, I meant ddx/driver combo
<freemangordon>
only vrfb will remain
<freemangordon>
but, d4 being our 'flagship'...
<freemangordon>
anyway, seems I have a long list of tasks for the weekend
<huckg>
I lost my connection to the chat when we were talking about 2d/3d accel. I installed mesa-utils and tried to run glxgears and got this: Error: glXCreateContext failed.
<uvos>
huckg: glx is only desktop gl
<uvos>
egl dose both
<uvos>
es2_gears uses gles2 via egl
_inky has quit [Ping timeout: 240 seconds]
<uvos>
*es2gears
<huckg>
yes es2gears runs. Is there any of the output useful to you?
<uvos>
no
<uvos>
unless perf is bad for some reason
inky_ has quit [Ping timeout: 240 seconds]
inky_ has joined #maemo-leste
<Wizzup>
uvos: re: libsdl2 not yet, let me look at this after work (say 11pm)