lel | tallero opened an issue: https://github.com/maemo-leste/gtk/issues/1 (Where `GtkWidgetTapAndHoldFlags` is (was) defined?) | 00:55 |
---|---|---|
lel | tallero opened an issue: https://github.com/maemo-leste/bugtracker/issues/568 (Where `GtkWidgetTapAndHoldFlags` is (was) defined?) | 09:12 |
lel | parazyd transferred an issue: https://github.com/maemo-leste/gtk/issues/1 (Where `GtkWidgetTapAndHoldFlags` is (was) defined?) | 09:12 |
lel | MerlijnWajer created a repository: https://github.com/maemo-leste/libresource | 10:58 |
lel | MerlijnWajer created a repository: https://github.com/maemo-leste/ohm-plugins-misc | 12:12 |
Wizzup | Can anyone with a n900 confirm that the leds from mce still work with latest image + upgraded to -devel stuff? | 14:02 |
Wizzup | uvos: ping | 14:40 |
Wizzup | freemangordon: btw: https://wiki.merproject.org/wiki/Nemo/Audio/MainVolume | 15:05 |
Wizzup | also https://wiki.merproject.org/wiki/Nemo/Audio#Mainvolume | 15:05 |
Wizzup | uvos: ohmd seems to react to hp plug just fine on n900, so that's good news | 16:07 |
Wizzup | it also has support for fmradio, so that'll be fun if that "just works" | 16:07 |
Wizzup | with the pulseaudio alsa-config for the n900 (instead of UCM) I can also switch audio for the apps to earpiece, headphones or speakers | 16:07 |
Wizzup | It looks like the volume handling is a bit different, so we'll have to decide if we use their approach (mainvolume plugin) or the old maemo method | 16:08 |
Wizzup | it also nicely attempts to disable the fmradio broadcast when hp is plugged in | 16:14 |
Wizzup | cool | 16:14 |
Wizzup | anyone with a sailfishos phone here? | 16:21 |
Wizzup | I was wondering what this would yield: rpm -qf /etc/pulse/xpolicy.conf | 16:21 |
Wizzup | uvos: have you seen toyed with this before? https://wiki.maemo.org/Community_SSU/Features/hildon-desktop | 16:37 |
Wizzup | (some of those would be good to try on software gl too: what if all transitions are set to 0 ms, blur disabled, etc) | 16:38 |
bencoh | I'm not certain the user can really disable everything using transitions.ini | 16:50 |
bencoh | but that would be cool | 16:50 |
Wizzup | probably not | 16:51 |
Wizzup | but we control it, so if it makes a difference we could consider some of that | 16:51 |
bencoh | for software egl I guess it would | 16:51 |
bencoh | for n900, I doubt it | 16:51 |
Wizzup | yeah | 16:51 |
Wizzup | there is also some stuff about xdamage events wrt rotation | 16:51 |
bencoh | reducing animations on n900 does not necessarily speed it up | 16:52 |
bencoh | it's funny / silly, but if you reduce animations too much on n900/fremantle, it feels kinda jerky | 16:52 |
Wizzup | mhm | 16:53 |
uvos | Wizzup: hmm? | 19:45 |
Wizzup | uvos: what part? | 19:45 |
uvos | ping | 19:45 |
uvos | what do you want | 19:46 |
Wizzup | I don't remember :) | 19:46 |
uvos | oh | 19:46 |
uvos | ok | 19:46 |
Wizzup | made a lot of progress on audio front though | 19:46 |
uvos | ragarding the transistions ini | 19:46 |
uvos | i do have the roataion animation disabled | 19:46 |
uvos | but really reduceing those timers to 0 is not so usefull | 19:46 |
Wizzup | does it get rid of the noise upon rotation? | 19:46 |
uvos | no thats the kernel | 19:47 |
Wizzup | ok | 19:47 |
uvos | that landed with the new omapdrm code | 19:47 |
uvos | in 5.10 i think | 19:47 |
Wizzup | ok | 19:47 |
uvos | hildon is quite inefficant anyhow and will go through the motions of the animation either way | 19:47 |
uvos | (ie it will create and distroy the surfaces) | 19:47 |
uvos | so reducing the timer is effectively pointless | 19:47 |
Wizzup | ok, we could probably write some code to skip that, but I am not sure if that helps muhc if we still 3d render everything (which I guess we will) | 19:48 |
uvos | sure | 19:48 |
Wizzup | right | 19:48 |
Wizzup | it's also not relevant, we mostly have working 3d for our purposes | 19:48 |
uvos | the main problem is that hildon is composing everything | 19:48 |
uvos | for no real reason | 19:48 |
uvos | imo | 19:48 |
Wizzup | do you mean upon expose, or always | 19:48 |
uvos | allways | 19:49 |
Wizzup | and is that indeed what affects llvmpipe performance and such? I didn't measure | 19:49 |
uvos | yes | 19:49 |
uvos | without this the apps would be renderd by x | 19:49 |
uvos | and not though llvmpipe at all | 19:49 |
Wizzup | can clutter do that? | 19:49 |
uvos | as is the architecture forces all of the apps to be renderd to textures | 19:49 |
uvos | and then these textures are fed to the 3d engine (or llvmpipe) | 19:49 |
uvos | can clutter do what? | 19:49 |
uvos | not compose? | 19:50 |
uvos | thats not related to cluter per say | 19:50 |
Wizzup | I mean, wouldn't everything still be a 3d render? | 19:50 |
uvos | no | 19:50 |
Wizzup | hmm, so if we want to pursue a llvmpipe hildon-desktop with no eye candy we could maybe attempt that at some point | 19:50 |
Wizzup | (skip animations, disable compositing) | 19:50 |
uvos | ok so heres the deal: | 19:50 |
uvos | so right now hildon asks x to put all of the xwindows into offscreen texutres which it feeds clutter and then transforms and renders all the windows itself. | 19:51 |
uvos | this rendering is done by h-d via cluter via gl calls | 19:52 |
uvos | this is what is slow | 19:52 |
Wizzup | right | 19:52 |
uvos | regardless of animations | 19:52 |
uvos | this makes all the animations easy and allows the task switcher to show live tiles | 19:52 |
uvos | in rality h-d could just let x render everything, and any thing it wants to show (the title bar, hildon home etc) could be real x windows that contain clutter surfaces instead of just clutter surfaces that hildon renders | 19:53 |
uvos | hildon could still display all the same animations | 19:53 |
uvos | by asking x for a single buffer before the animation | 19:53 |
uvos | and then performing the animation with that buffer | 19:54 |
uvos | then the rendering would never pass though gl | 19:54 |
uvos | except durin an animation | 19:54 |
uvos | the only thing you would have to sacrifice is the live switcher tiles (they would have to be screenshots of the app in its last focused state) | 19:54 |
uvos | this would then work fine on x11 with no accell | 19:55 |
uvos | as x11's own rendering is very cpu optimized it should be fast(ish) even on n900 | 19:55 |
Wizzup | right, but rendering seperate windows and such would be a lot of (re) work | 19:56 |
uvos | right | 19:56 |
uvos | it makes no sense to implement this kind of thing | 19:57 |
Wizzup | yeah | 19:57 |
uvos | from a manpower perspective | 19:57 |
uvos | im just saying the way they did it is kind dumb | 19:57 |
uvos | as this btw also wastes a screen sized buffer worth of ram for every app thats open | 19:57 |
uvos | which im sure hurts bad on n900 | 19:58 |
uvos | thats 1.5mv | 19:58 |
uvos | *mb | 19:58 |
uvos | per app | 19:58 |
uvos | just down the drain | 19:58 |
uvos | anyhow cool progress on the audio stuff | 19:59 |
Wizzup | yeah, hopefully it'll all come together soonish | 20:01 |
Wizzup | I think most of the sw is now packaged and built in the CI | 20:01 |
Wizzup | if I understand some of this correctly, UCM support probably isn't all that problematic | 20:01 |
kona | is there some way to get the virtual keyboard to send keystrokes direct to the terminal? | 23:16 |
kona | or a way to send characters without a CR/LF for use in e.g. vi? | 23:19 |
kona | i guess the latter is what i am looking for since my pinephone doesn't seem to support BT kb. | 23:19 |
stano_ | hi kona | 23:21 |
kona | hi! | 23:21 |
stano_ | can we pm? | 23:21 |
kona | yes, thanks for asking | 23:21 |
uvos | kona: you cant use the vkb in immidate mode | 23:29 |
uvos | kona: however you can send text with cr/lf to xterm | 23:30 |
uvos | kona: just type the text and click above the vkb to close it | 23:30 |
kona | oh, hmm. | 23:30 |
kona | awesome, thanks! | 23:31 |
uvos | you can also get subtaly different results (sometimes usefull) by opening the vkb with volume up | 23:31 |
uvos | instead of a tap on the input field | 23:31 |
kona | oh, that is great, too | 23:32 |
uvos | i do have to say that the vkb of maemo is simply bad | 23:33 |
uvos | its a weakness that stems from the fact that the devices we mostly use have hardware keyboards | 23:33 |
kona | it used to work pretty well on the 810 | 23:34 |
kona | but i guess that's like, a decade ago :) | 23:34 |
uvos | even though i never used a n810 i know the vkb still sucked even then, at least in implementation, because the current behind the scenes implementation is explicitly also for the n810 (ie its the same) | 23:35 |
kona | oh, hmm. | 23:35 |
kona | yeah, i usually used the hw kb | 23:36 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!