Wizzup | ok | 00:00 |
---|---|---|
Wizzup | thanks | 00:00 |
Wizzup | I also need to add the syslog per daemon and no-services-restart stuff to -devel | 00:00 |
Wizzup | uvos: so add --disable-video-directfb --enable-video-kmsdrm --disable-kmsdrm-shared to libsdl2 rules? | 00:03 |
Wizzup | uvos: seems to be in debian/rules already at least in master for libsdl2 | 00:04 |
Wizzup | ah, I see, parazyd added stuff | 00:04 |
Wizzup | uvos: so shall I just revert most of his commits? | 00:04 |
uvos | Wizzup: ? its not in sdl2 | 00:04 |
uvos | please link where you see it | 00:05 |
Wizzup | it is in master of libsdl2 | 00:05 |
Wizzup | just parazyd changed it for maemo/beowulf-devel and such | 00:05 |
Wizzup | https://github.com/maemo-leste-upstream-forks/libsdl2/blob/master/debian/rules | 00:05 |
uvos | right | 00:05 |
uvos | so you can just delete | 00:06 |
uvos | maemo-leste-upstream-forks / | 00:06 |
uvos | libsdl2 | 00:06 |
uvos | we dont need it anymore | 00:06 |
uvos | if kms is enabled in debian libsdl2 | 00:06 |
uvos | and revert 575c4279972522107dd10dfd5a9ac445c40794e5 in libsdl1.2 | 00:07 |
Wizzup | I am not sure if stuff will downgrade automatically | 00:07 |
uvos | hmm | 00:07 |
uvos | so how do we unfork maemo-leste-upstream-forks . | 00:08 |
Wizzup | I can just revert his commits and build it again | 00:08 |
uvos | sure | 00:08 |
uvos | but since obv. the point of that repo is to be temprary | 00:08 |
uvos | it should realy be removed now | 00:08 |
Wizzup | we can force remove it with meta, or just not build it again for beowulf+1 | 00:08 |
uvos | ok | 00:09 |
Wizzup | building libsdl1.2 for -devel | 00:09 |
Wizzup | I will still need to figure out how to run the kernel postinst in our n900 image build | 00:10 |
Wizzup | not so fun | 00:10 |
uvos | no idea | 00:10 |
Wizzup | yeah :) | 00:10 |
uvos | just fix zimage on n900 maybe | 00:10 |
Wizzup | it lacks both zImage and uImage | 00:11 |
Wizzup | and that requires everyone to have newer uboot, but yeah | 00:11 |
uvos | why would it lack zImage | 00:11 |
Wizzup | not sure, it had vmlinuz | 00:11 |
Wizzup | (with version) | 00:11 |
Wizzup | maybe the postinst errored somehow | 00:11 |
Wizzup | remind me about the libsdl2 tomorrow, need to think about it for a bit :) | 00:15 |
uvos | hmm? | 00:15 |
uvos | what is there to think about | 00:15 |
Wizzup | we can maybe force remove our version | 00:16 |
Wizzup | through meta | 00:16 |
Wizzup | if people dist-upgrade at least | 00:16 |
uvos | ok | 00:16 |
Wizzup | working on the news post btw, but will probably want to have the n900 image fixed before we publish it | 00:16 |
uvos | no doubt | 00:16 |
uvos | in fact i would delete the image | 00:16 |
uvos | on madevu | 00:16 |
uvos | so no one installs it | 00:16 |
Wizzup | I renamed the dir :) | 00:16 |
uvos | ok | 00:16 |
Wizzup | freemangordon: btw, if you want a break from other stuff, having the rtcom presence status applet could be fun, although it might depend on many other libs | 00:17 |
uvos | i see you also build droid3 | 00:18 |
uvos | did you test that? | 00:18 |
Wizzup | I didn't test the most recent image yet | 00:18 |
Wizzup | I did test the droid4 one | 00:19 |
Wizzup | and with you testing the bionic and me the droid4, it's probably fine, but yeah | 00:19 |
uvos | well its notable | 00:19 |
Wizzup | mhm | 00:19 |
uvos | because thats the first image released | 00:19 |
Wizzup | I plan to test it | 00:19 |
Wizzup | libsdl1.2 went through to -devel | 00:21 |
uvos | ok | 00:21 |
uvos | should not have chagned at all | 00:21 |
uvos | since those defines have no effect on sdl1.2 | 00:22 |
Wizzup | check | 00:22 |
Wizzup | btw | 00:23 |
Wizzup | if you have any screenshots of the status applet shows 2 or more days remaining on battery, I can use them for the blog | 00:23 |
Wizzup | s/blog/update/ | 00:23 |
Wizzup | I'll get some on the d4 in a bit, but iirc your bionic lasts longer? | 00:24 |
uvos | dont have any | 00:24 |
uvos | but i can see if i can catch it at some point | 00:24 |
uvos | my d4 also has greater than stock 1900mah battery | 00:24 |
Wizzup | mine is estimated at 1100mAh or so and shows 2 days at 90% with modem on | 00:25 |
uvos | yeah mine is huge in comperasin | 00:25 |
uvos | 2300 nominal | 00:25 |
uvos | i get 3 easy | 00:25 |
dreamer | 73 | 00:26 |
dreamer | woops | 00:26 |
Wizzup | I am thinking of this update being a general update of all the stuff, and then do a separate one for the pinephone and also one for the droid4, just showing off the current features | 00:28 |
uvos | sounds like a lot of work | 00:28 |
uvos | but yeah | 00:28 |
uvos | sounds good | 00:28 |
Wizzup | maybe, I don't think it should be too muh work | 00:28 |
uvos | btw | 00:30 |
xmn | Any time you can show off all the hard work you guys have put into this project is a good thing I would say. My less then 2 cents | 00:30 |
uvos | we should load-module module-switch-on-port-available for pulse | 00:31 |
uvos | by default | 00:31 |
lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/602 (Fix droid4 ofono bugs/quircks) | 00:31 |
uvos | to make the audio setup work fully on mapphones/pp | 00:31 |
Wizzup | hm, what does this do exactly? I mean the name is pretty obvious | 00:31 |
uvos | exactly what it says on the tin | 00:32 |
uvos | it switches to higher priority ucm audo paths | 00:32 |
uvos | when they become available | 00:32 |
Wizzup | on plug events? | 00:32 |
uvos | ie because you plug in a hp | 00:32 |
Wizzup | I think this alrady works for me | 00:32 |
Wizzup | maybe I already have this? | 00:32 |
uvos | yes | 00:32 |
uvos | because i told you to add it to your file :P | 00:32 |
Wizzup | mhm | 00:32 |
lel | MerlijnWajer labeled an issue: https://github.com/maemo-leste/bugtracker/issues/602 (Fix droid4 ofono bugs/quircks) | 00:33 |
uvos | Wizzup: btw ill do alarms next, audio wise | 00:35 |
uvos | Wizzup: plan here is to have another profile with the speaker as the highest priorty path | 00:35 |
uvos | profile gets its own volume too (ofc as is default) | 00:35 |
uvos | and just have the alarms play on the profile related sink | 00:36 |
uvos | that way when you switch to it every thing else gets paused | 00:36 |
uvos | and alarm plays at fixed volume | 00:36 |
Wizzup | I think alarm volume is set somewhere or something, right? | 00:37 |
Wizzup | I don't really remember | 00:37 |
uvos | sure yeah | 00:37 |
uvos | its in profiled | 00:37 |
Wizzup | right | 00:38 |
Wizzup | I haven't touched that on fremantle in a while :) | 00:38 |
uvos | setting the alarm sink/profile volume based on the profiled is not hard | 00:38 |
uvos | i could have the volume applet do it (it dose so for calls allready) but i dont like this mutch | 00:39 |
uvos | really i we should stip that from teh volume applet into some centralised place | 00:39 |
uvos | in fremantle it looks to be haparzardly placed all over the place | 00:40 |
Wizzup | we have some other architecture things to figure out wrt the modem as well | 00:40 |
Wizzup | I had the modem drop off of usb for a bit and nothing powered it up again | 00:40 |
Wizzup | uvos: do you have a list of mce changes since last release? I can try to make one based on git commit history | 00:54 |
uvos | Wizzup: no | 00:56 |
uvos | Wizzup: also mce was very quiet since then | 00:56 |
Wizzup | there is cpu offlining, some lock screen fixes | 00:56 |
uvos | i think the volume keys are the only feature | 00:56 |
Wizzup | right and volume keys | 00:56 |
freemangordon | alarm volume is not set, it is always @ max | 07:58 |
freemangordon | also, native device orientation can but get from xrandr, we don;t need some device specific config | 07:58 |
freemangordon | *can be | 07:59 |
freemangordon | and again, I prefer to discuss architecture decision before those being coded | 08:00 |
freemangordon | *decisions | 08:00 |
freemangordon | I am not going to deduce about behaviour based on code | 08:02 |
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 | 08:03 |
Wizzup | freemangordon: check | 11:10 |
_uvos_ | fremangordon: yes we do what is "native" for the orientation of the volume buttons | 11:10 |
_uvos_ | is totaly independant of the scann direction of the display | 11:10 |
_uvos_ | of course the alarm volume is set | 11:12 |
_uvos_ | just because the proparty isent user faceing in the ui (another large deficancy in fremantle) dosent make it not set | 11:13 |
_uvos_ | irc.txt broke again btw | 11:16 |
Wizzup | we also have the other logs | 11:16 |
Wizzup | let me fix it again though | 11:16 |
_uvos_ | sure | 11:16 |
Wizzup | irc.txt is just running 'ii' | 11:17 |
Wizzup | I guess it doesn't handle some stuff well | 11:17 |
_uvos_ | i just find the ui of whitequark very bad | 11:17 |
_uvos_ | i mean i have to know todays date to find the latest messages | 11:17 |
_uvos_ | also grep | 11:17 |
Wizzup | should be ok again | 11:18 |
_uvos_ | test.... | 11:19 |
_uvos_ | no | 11:19 |
Wizzup | let's give if a few mins just in case it's some cache/buffer thing | 11:21 |
freemangordon | uvos: volume buttons *should not* depend on stuff like *native* orientation, bot on top application orientation | 11:30 |
freemangordon | please, do not try to oversmart Nokia in terms of UX | 11:30 |
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 | 11:31 |
uvos | this is about what orientation they are in while the display is off | 11:31 |
freemangordon | still, the bahaviour shall be cosistent | 11:32 |
uvos | volume up | 11:32 |
freemangordon | imagine if you lock your screen with media player in portrait | 11:32 |
uvos | is to be up on the device | 11:32 |
uvos | at all times | 11:32 |
uvos | if the display is off | 11:32 |
uvos | period | 11:32 |
freemangordon | no | 11:32 |
freemangordon | sorry | 11:32 |
freemangordon | this is not consistent | 11:33 |
uvos | so what you want is: | 11:33 |
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 | 11:33 |
freemangordon | mhm | 11:34 |
uvos | and when i go to change the volume i must somehow remember the state the device was in | 11:34 |
freemangordon | and, it is not about what *I* want | 11:34 |
uvos | 30 minutes ago | 11:34 |
uvos | this is stupidity | 11:34 |
freemangordon | applet is already registered to mce events | 11:34 |
freemangordon | so it is about one integer damamit! | 11:34 |
uvos | WHILE THE DISPLAY IS OFF | 11:34 |
uvos | there is no rotating anything in this state | 11:35 |
freemangordon | yes, while the display is off | 11:35 |
uvos | no | 11:35 |
uvos | mce will not and cann not | 11:35 |
uvos | have the accel on at all times | 11:35 |
uvos | and even then | 11:35 |
freemangordon | you don;t follow | 11:35 |
uvos | its not like the accel is some magic bullet | 11:35 |
uvos | im sorry you are wrong | 11:35 |
freemangordon | lemme explain | 11:35 |
uvos | and the behavior of the original code wasent like that either | 11:35 |
uvos | and your intended behavior | 11:35 |
uvos | is more than the hight of folly | 11:35 |
freemangordon | could you listen for a while? | 11:36 |
freemangordon | ? | 11:36 |
freemangordon | I assume yes, so: | 11:36 |
freemangordon | it is not about what orientation is currently the device in (with display off) | 11:37 |
freemangordon | it is about what orientation device was before display went off | 11:37 |
freemangordon | *the last* orientation in terms of what h-d did last | 11:38 |
freemangordon | not what accel said | 11:38 |
uvos | yes | 11:38 |
uvos | and that is stupid | 11:38 |
freemangordon | says who? | 11:38 |
uvos | to the highest degree | 11:38 |
uvos | and not what the code ever did | 11:38 |
freemangordon | I give up | 11:38 |
freemangordon | this is not a discussion | 11:38 |
uvos | this forces you to know | 11:38 |
Wizzup | freemangordon: how does this work on fremantle? | 11:38 |
Wizzup | I don't think it works like this on fremantle | 11:38 |
uvos | what orientation the device was in when the display whent off | 11:38 |
uvos | this is VERY bad | 11:39 |
Wizzup | at least not on my n900 - I just tried | 11:39 |
uvos | the user is not psychic | 11:39 |
freemangordon | how did you try? | 11:39 |
Wizzup | freemangordon: I set volume off, help it on portrait, locked device, tried to change volume | 11:41 |
Wizzup | by pressing the top (in landscape left) volume button a few times | 11:41 |
Wizzup | and nothing happened | 11:41 |
Wizzup | s/help/held/ | 11:41 |
Wizzup | I did see h-d rotate to portrait as well | 11:41 |
Wizzup | I am on cssu | 11:42 |
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 | 11:43 |
freemangordon | look here https://github.com/maemo-leste/maemo-statusmenu-volume/blob/d6c3ffa8de080e82fe66881163594da2ca73ce19/src/item.c#L1074 | 11:44 |
freemangordon | this is the original code | 11:44 |
freemangordon | why it does not work for you I don;t know, but the intention is clear | 11:45 |
freemangordon | Wizzup: I guess you should have something running for this to take place | 11:46 |
freemangordon | like media player or phoneui | 11:46 |
humpelstilzchen[ | .o0(make it user configurable) | 11:48 |
Wizzup | freemangordon: I had the alarm ui open | 11:48 |
freemangordon | did you have a look at the code? | 11:49 |
freemangordon | because it is clear what it should do | 11:49 |
Wizzup | humpelstilzchen[: yo - did the pine64 kernel fix the things you wanted it to fix? :) | 11:49 |
freemangordon | why it doesn;t work for you, well, I don;t know | 11:49 |
Wizzup | freemangordon: this gets set only once it seems https://github.com/maemo-leste/maemo-statusmenu-volume/blob/d6c3ffa8de080e82fe66881163594da2ca73ce19/src/item.c#L1359 | 11:50 |
freemangordon | but, for me it works | 11:50 |
freemangordon | no, it gets set on screen resize | 11:50 |
Wizzup | ah no, here https://github.com/maemo-leste/maemo-statusmenu-volume/blob/d6c3ffa8de080e82fe66881163594da2ca73ce19/src/item.c#L570 | 11:50 |
freemangordon | and for sure on the device in front of me it works like that | 11:50 |
freemangordon | buttons got swapped | 11:51 |
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 | 11:51 |
humpelstilzchen[ | Wizzup: Thx, did not try the new package yet, but should have fixed it, since I compiled & tested exactly this config | 11:51 |
Wizzup | combine that with the fact that tklock doesn't typically render in portrait mode, and it's just confusing | 11:51 |
Wizzup | humpelstilzchen[: ok, let me know if you need help testing it, not sure if you used the -devel repos before | 11:52 |
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* | 11:52 |
uvos | fremantle "UX" (realy the hmi) is _terrible_ quite often | 11:54 |
uvos | its not some gospel | 11:54 |
uvos | also when locked | 11:54 |
uvos | the widget allways reads landscape | 11:54 |
uvos | might be some ddx thing | 11:54 |
uvos | but thats how it works | 11:54 |
uvos | "I rarely change the volume when the screen is locked because I don't know what it will do" | 11:55 |
uvos | right thats the problem | 11:55 |
Wizzup | freemangordon: I think is we set the value for n900 in leste-config-n900 it should not break the default ux? | 11:55 |
freemangordon | how is n900 related here? | 11:55 |
uvos | with freemangordon's inteded behavior the user has to be Psychic | 11:55 |
uvos | there is not telling how the volume keys will react before pressing them | 11:56 |
Wizzup | I wouldn't mind having a psychic connection to my bt :) | 11:56 |
Wizzup | for my n900* | 11:56 |
Wizzup | to my n900* | 11:56 |
Wizzup | ugh | 11:56 |
freemangordon | have to attend work mtg, ttyl | 11:56 |
Wizzup | freemangordon: afaik there is an option, swap_on_rotate | 11:56 |
uvos | no | 11:57 |
uvos | turning that off | 11:57 |
uvos | makes it never swap at all | 11:57 |
uvos | ie also not when the display is on | 11:57 |
uvos | like is really the best "ux" | 11:57 |
uvos | because it dosent break musscel memory | 11:57 |
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 | 11:57 |
Wizzup | the PR I looked at didn't seem to touch that code other than through the config var | 11:58 |
uvos | that is correct | 11:58 |
uvos | turning it on again | 11:58 |
uvos | makes it like fremantle | 11:58 |
uvos | however thats not how fremangordon wants it to work | 11:58 |
uvos | maybe because the widget reads the wrong orientation while off | 11:58 |
uvos | but it dose the same in non cssu fremantle here | 11:59 |
Wizzup | right, it sounds like it works for him on fremantle, so maybe it's a ddx/lockscreen thing | 11:59 |
Wizzup | i.e. that bug is elsewhere | 11:59 |
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 | 12:00 |
uvos | and we should not be held to it | 12:00 |
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 | 12:02 |
humpelstilzchen[ | Wizzup: with -devel you mean https://maedevu.maemo.org/leste beowulf-devel main (...)? | 12:03 |
uvos | also yeah, while in tklock it is broken | 12:03 |
uvos | since tklock rotates itself | 12:03 |
uvos | vtklock | 12:03 |
uvos | i mean | 12:03 |
uvos | so thats really terrble to | 12:03 |
uvos | (really tklock should just not rotate itself) | 12:03 |
uvos | same problem with applications that rotate themselves | 12:04 |
uvos | (ie brainparty and cloudgps) | 12:04 |
uvos | again applicaitons roating themselves are broken | 12:04 |
uvos | they should never do that | 12:04 |
Wizzup | humpelstilzchen[: yes | 12:06 |
Wizzup | uvos: maybe we should make two packages: hildon-config-nokia and hildon-config-<somethingelse> | 12:10 |
Wizzup | nokia mimics fremantle | 12:10 |
Wizzup | for all these things, h-d config, volume applet config | 12:11 |
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 | 12:22 |
humpelstilzchen[ | so I told apt to downgrade | 12:22 |
humpelstilzchen[ | uname says the kernel is from yesterday | 12:23 |
humpelstilzchen[ | Jenkins seems to know 7.2 https://phoenix.maemo.org/job/pine64-kernel-source/68/ | 12:25 |
Wizzup | hm, yeah, I didn't increase the version in debian/changelog and might have done some repro stuff removing it, that's my bad | 12:25 |
Wizzup | I'll have to increase that number some then for stable | 12:26 |
Wizzup | thanks for testing | 12:26 |
Wizzup | (and the pr) | 12:26 |
uvos | Wizzup: btw clutter | 12:33 |
uvos | Wizzup: with fix for pp dident build for armhf | 12:33 |
Wizzup | uvos: hm, not the end of the world but yeah we should probably fix | 12:34 |
Wizzup | /usr/bin/ld: cannot find -lGLESv2 | 12:35 |
Wizzup | /usr/bin/ld: cannot find -lEGL | 12:35 |
Wizzup | hm | 12:35 |
Wizzup | let me just re-run it | 12:35 |
uvos | you did test the pp changes on pvr right? | 12:35 |
Wizzup | yup | 12:35 |
uvos | not taht we build broken clutter direct to stable this way | 12:36 |
Wizzup | it built before for -devel | 12:36 |
uvos | ok | 12:36 |
Wizzup | I think this is just related to the order in which I built things | 12:36 |
Wizzup | I can't imagine this breaking pvr | 12:36 |
uvos | ok | 12:36 |
Wizzup | uvos: it's there now | 12:47 |
Wizzup | thanks for noticing | 12:47 |
huckg | [bionic] I ran into this when doing apt update, apt upgrade:The following packages have unmet dependencies: | 16:34 |
huckg | libegl1-sgx-omap4 : Conflicts: libegl1 (>= 1.3.0-1) | 16:34 |
huckg | libgles1-sgx-omap4 : Conflicts: libgles1 (>= 1.3.0-1) | 16:34 |
huckg | libgles2-sgx-omap4 : Conflicts: libgles2 (>= 1.3.0-1) | 16:34 |
huckg | Conflicts: libgles2-mesa | 16:34 |
uvos | you have to do dist-upgrade | 16:37 |
uvos | not sure if that helps | 16:37 |
uvos | but its a general rule | 16:37 |
huckg | Thanks, yes it is upgrading now. | 16:40 |
uvos | should be a massive performance increase | 16:41 |
uvos | with the new 3d driver | 16:41 |
huckg | One thing I have noticed is that alot of apps complain about not finding /var/run/user/1000 | 16:43 |
huckg | got an error during the upgrade, hildon-desktop call to flock failed. | 16:45 |
huckg | Resource temporarily unavailable | 16:47 |
Wizzup | yes, I also noticed this, really annoying | 16:48 |
Wizzup | It seems to be some openrc thing | 16:48 |
Wizzup | I think having the rc-policy.d thing to just prevents restarts of these services is the solution for now | 16:49 |
huckg | Setting up hildon-desktop:armhf (1:2.2.185+2m7.1) ... | 16:51 |
huckg | * Call to flock failed: Resource temporarily unavailable | 16:51 |
huckg | * ERROR: hildon-desktop stopped by something else | 16:51 |
huckg | invoke-rc.d: initscript hildon-desktop, action "restart" failed. | 16:51 |
huckg | dpkg: error processing package hildon-desktop:armhf (--configure): | 16:51 |
huckg | installed hildon-desktop:armhf package post-installation script subprocess retu | 16:51 |
huckg | rned error exit status 1 | 16:51 |
huckg | Errors were encountered while processing: | 16:51 |
huckg | hildon-desktop:armhf | 16:51 |
uvos | this isent a real problem | 16:52 |
uvos | that init script is a dummy | 16:52 |
Wizzup | uvos: yes but apt stops after this | 16:53 |
Wizzup | uvos: and it doesn't configure the rest of the packages | 16:54 |
Wizzup | the only way I was able to work around it without rebooting was renaming the init script | 16:54 |
huckg | Sorry I brought up 2 issues at once. | 16:54 |
uvos | just stop the script | 16:54 |
Wizzup | I am pushing a leste-config change now with /usr/sbin/policy-rc.d | 16:54 |
uvos | then | 16:54 |
Wizzup | uvos: I did this, it won't stop, the flock thing just hangs | 16:54 |
uvos | Wizzup: so? | 16:54 |
uvos | /etc/init.d/hildon-desktop reset | 16:54 |
Wizzup | it is zap, but it still doesn't help | 16:54 |
uvos | ok | 16:55 |
Wizzup | for me at least | 16:55 |
Wizzup | I pushed a basic policy-rc.d to -devel | 16:55 |
Wizzup | if you have suggestions for a dirname where it can read additional blacklists lmk | 16:55 |
Wizzup | /etc/policy-rc.d seemed awkward | 16:55 |
huckg | uvos: when you suggested /etc/init.d/hildon-desktop reset did you mean restart? | 17:00 |
Wizzup | huckg: are you on -devel? | 17:01 |
huckg | no | 17:01 |
Wizzup | ok | 17:02 |
Wizzup | huckg: so my temporary workaround was mv /etc/init.d/hildon-desktop /etc/init.d/hildon-desktop_ | 17:02 |
Wizzup | and then move it back, but I'm pushing a fix to -devel for this stuff | 17:02 |
huckg | Wizzup: thanks, that worked. There was this during the upgrade: *** OMINOUS WARNING ***: /usr/share/alsa/ucm2/Mapphone_Audio/HiFi.conf is not li | 17:07 |
huckg | nked to either HiFi.conf.leste or HiFi.conf.leste-orig | 17:07 |
uvos | huckg: right you chainged it | 17:09 |
huckg | maybe that is because I previously edited HiFi.conf | 17:09 |
uvos | its not a problem rn | 17:10 |
uvos | but it will be if we ever change it | 17:11 |
uvos | to add new profiles etc | 17:11 |
Wizzup | hm I just realised we do have a non-functioning special keys keyboard on stable now | 17:21 |
uvos | i dont think it worked in stable before either | 17:22 |
uvos | pretty sure it broke unoticed quite some time before the last promote | 17:22 |
Wizzup | on the n900 this means you cannot type the pipe symbol | 17:25 |
uvos | yeah | 17:25 |
Wizzup | '|' | 17:25 |
uvos | porblem is i reverted him quite far | 17:25 |
uvos | and it made no difference | 17:25 |
uvos | so im not sure what cuased it | 17:25 |
Wizzup | does the code to act on these buttons get triggered at all, and maybe the svc showing just doesn't work? | 17:26 |
Wizzup | I have no idea what exactly broke | 17:26 |
uvos | no it dosent | 17:26 |
uvos | i never gets the signal | 17:26 |
uvos | to open | 17:26 |
Wizzup | ok, so issuing the request over dbus still works? | 17:26 |
uvos | thats not how it works | 17:26 |
uvos | it uses xatoms | 17:26 |
uvos | to transfer all keybord input | 17:27 |
uvos | into gtk2 windows | 17:27 |
uvos | back to him | 17:27 |
uvos | (yes this is nuts :P) | 17:27 |
uvos | and then him acts on that | 17:27 |
uvos | theoreticly | 17:27 |
Wizzup | btw side note if you revert hildon-input-method-framework stuff you also need to rebuild other pkgs iirc | 17:27 |
uvos | i reverted him | 17:27 |
uvos | theres only on change to himf | 17:28 |
uvos | and dident look related at all | 17:28 |
uvos | but you could try that | 17:28 |
Wizzup | right the enter key unredirect | 17:28 |
Wizzup | even that is too old, I am pretty sure it did work before | 17:29 |
uvos | Wizzup: so the code to open the special keyboard plugin is here https://github.com/maemo-leste/hildon-input-method-plugins/blob/c46e30149633317d38c5d826d5a363c191a9834d/hildon-im-keyboard-monitor/hildon-im-keyboard-monitor.c#L469 | 17:31 |
uvos | it never gets tehre | 17:31 |
uvos | you can trace the code backwards to him | 17:32 |
uvos | and there is a break there where its not passed allog i introduced | 17:32 |
uvos | i fixed this here: https://github.com/IMbackK/hildon-input-method/commit/efdc6389e68b8c1e6b070ac96e7413021a9628a5 | 17:32 |
uvos | but this dosent help | 17:32 |
uvos | as it never gets there either | 17:32 |
uvos | next step would be to figure out why it dosent get there | 17:32 |
Wizzup | did we build this fix? | 17:33 |
uvos | no | 17:34 |
uvos | i dident pr it | 17:34 |
uvos | since it dosent help | 17:34 |
uvos | i then coninued to investigate with him reverted to 71e6186e7a8ca675654bd9de9261aa067407c466 | 17:34 |
uvos | but dident make any progress | 17:34 |
uvos | note that i dident test this on n900 | 17:35 |
uvos | it might be that the problem at 71e6186e7a8ca675654bd9de9261aa067407c466 is only on the d4 | 17:35 |
Wizzup | were you ever able to raise this on the d4? | 17:35 |
uvos | yes | 17:35 |
uvos | bit i know it dident work at some time in the past (according to the bugtracker) | 17:36 |
uvos | so maybe 71e6186e7a8ca675654bd9de9261aa067407c466 and https://github.com/IMbackK/hildon-input-method/commit/efdc6389e68b8c1e6b070ac96e7413021a9628a5 work on n900 | 17:36 |
Wizzup | right | 17:36 |
uvos | but raising it on d4 did work at some point | 17:37 |
uvos | for sure | 17:37 |
freemangordon | uvos: never seen it working on d4 | 19:01 |
freemangordon | but it worked on n900 | 19:01 |
freemangordon | so, I think the bisect shall be done by testing on n900, if you plan to do so | 19:01 |
Wizzup | I can try to build this on my n900 | 19:02 |
freemangordon | Wizzup: actually there is '|' even in normal vkb | 19:03 |
freemangordon | you have to select numeric one and press shift | 19:03 |
freemangordon | Wizzup: don't waste your time, I'll look at it during the weekend | 19:04 |
Wizzup | freemangordon: ok, ty! | 19:05 |
Wizzup | another thing I noticed is that we specify layout to us in xorg conf | 19:05 |
Wizzup | not sure if we need that, since iirc we have /etc/default/keyboard for that | 19:05 |
Wizzup | huckg: is the new 2d/3d stuff working for you on bionic? it should be faster | 19:05 |
uvos | Wizzup: did you figure out what to do about libsdl2? | 19:08 |
huckg | Wizzup: yes, tried out qtbrowser and it seemed smoother. | 19:17 |
uvos | qtbrowser is unfotionatly not accelerated at all | 19:19 |
uvos | so it only benefits slightly | 19:19 |
freemangordon | uvos: still, rendering should be faster because of the blit is faster | 19:19 |
uvos | right | 19:19 |
uvos | and it is | 19:19 |
freemangordon | yeah, slightly | 19:19 |
uvos | but not to the extent of ff for instance | 19:19 |
freemangordon | yeah | 19:19 |
freemangordon | hmm, are you sure FF is accelerated? | 19:19 |
freemangordon | I think it is not, at least according to about:support | 19:21 |
uvos | it should be | 19:21 |
uvos | ok | 19:21 |
uvos | hmm | 19:21 |
freemangordon | most-probably it is not, because PVR is not whitelisted | 19:21 |
freemangordon | not 100%sure though, lemme check | 19:21 |
uvos | it gets unrealistic performance on videos tho | 19:21 |
freemangordon | uvos: BTW, what is this ddx crash? something with VTs | 19:22 |
uvos | if not accelerated | 19:22 |
uvos | freemangordon: switch vts | 19:22 |
uvos | and then back to the vt with x | 19:22 |
freemangordon | how> | 19:22 |
uvos | crash | 19:22 |
uvos | every time | 19:22 |
freemangordon | how? | 19:22 |
uvos | ssh, chvt | 19:22 |
freemangordon | chvt 0? | 19:22 |
uvos | sure | 19:22 |
freemangordon | chvt 7? | 19:22 |
uvos | or plug in a keyboard | 19:22 |
uvos | yes | 19:22 |
freemangordon | ok | 19:22 |
freemangordon | uvos: seems firefox wants opengl | 19:27 |
freemangordon | not gles | 19:27 |
uvos | for webgl | 19:28 |
freemangordon | not only | 19:28 |
freemangordon | for rendering too | 19:28 |
freemangordon | check in about:support: | 19:30 |
freemangordon | HW_COMPOSITING etc | 19:30 |
uvos | i have a hard time gorking what this means | 19:31 |
uvos | it sais available by default | 19:31 |
freemangordon | but disabled by platform :) | 19:33 |
freemangordon | I am trying to enable | 19:33 |
freemangordon | yeah, it searches for opengl | 19:33 |
uvos | its interesting that it manages mutch better performance in yt than mpv dose in native videos | 19:34 |
uvos | this allone made me assume it must be accelerated | 19:34 |
freemangordon | open about:config | 19:35 |
freemangordon | and set layers.accelerated.draw-fps to true | 19:35 |
freemangordon | and force-enabled to true | 19:36 |
freemangordon | restart FF and you'll see that it complains for missing opengl | 19:36 |
uvos | yeah | 19:37 |
uvos | also it scrolls at 35fps | 19:37 |
freemangordon | which site? | 19:37 |
uvos | just my homepage | 19:37 |
uvos | (simple) | 19:37 |
uvos | also irc.txt | 19:38 |
uvos | bbc is like 25 ish | 19:38 |
uvos | it suprises me it manages that mutch really | 19:38 |
freemangordon | maybe you did some tweaks, as here it scrolls with ~25 | 19:39 |
freemangordon | yeah, same then | 19:39 |
freemangordon | well, it should be way faster, but FF become so bloated nowadays | 19:39 |
freemangordon | uvos: do you plan to look at this panel power-on bug? | 19:41 |
uvos | not immiatly | 19:42 |
freemangordon | ok | 19:42 |
uvos | i find it fairly low priority | 19:42 |
uvos | since it mostly dosent hurt anyone | 19:42 |
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 | 19:43 |
freemangordon | DDX/rendering | 19:43 |
uvos | i dont think it has anything to do with ddx | 19:43 |
uvos | ok | 19:43 |
freemangordon | yeah, I meant ddx/driver combo | 19:43 |
freemangordon | only vrfb will remain | 19:43 |
freemangordon | but, d4 being our 'flagship'... | 19:44 |
freemangordon | anyway, seems I have a long list of tasks for the weekend | 19:44 |
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. | 20:22 |
uvos | huckg: glx is only desktop gl | 20:27 |
uvos | egl dose both | 20:27 |
uvos | es2_gears uses gles2 via egl | 20:28 |
uvos | *es2gears | 20:29 |
huckg | yes es2gears runs. Is there any of the output useful to you? | 20:31 |
uvos | no | 20:31 |
uvos | unless perf is bad for some reason | 20:31 |
Wizzup | uvos: re: libsdl2 not yet, let me look at this after work (say 11pm) | 20:46 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!