| freemangordon | uvos: https://pastebin.com/qi3etigN | 08:30 |
|---|---|---|
| freemangordon | keep in mind that display is not locked, just the brightness is set to 0 | 08:37 |
| freemangordon | Wizzup: what is this? https://github.com/maemo-leste/maemo-system-services/commit/091af968e7a30fee440b4809dee0f5b1973594ef | 08:57 |
| Wizzup | freemangordon: I think if we remove that, it will 'fail' to start due to some openrc timeout | 11:06 |
| freemangordon | though so, just wanted a confirmation :) | 11:08 |
| freemangordon | Wizzup: are you aware of any type of signal that is send by gnome, kde, whatever when it starts/is started? | 11:10 |
| freemangordon | uvos removed MCE_BOOTUP_SUBMODE but we shall restore that. the issue is that it is cleared on hildon-desktop specific dbus signal | 11:11 |
| freemangordon | before I start arguing on whether mce should care about anything non h-d, I would like to know if there exists a standard way of understanding when bootup sequence is over | 11:14 |
| Wizzup | yes, we need that | 11:14 |
| Wizzup | I don't know if there's any standard way, probably not... | 11:14 |
| * freemangordon checks what nemo guys do | 11:16 | |
| freemangordon | ok, I guess we can create "boot" modules that are specific for each usecase and detect boot process end | 11:24 |
| freemangordon | and we can have hildon_boot module that waits for h-d to start | 11:25 |
| freemangordon | otherwise, this is what SF do: https://github.com/sailfishos/mce/blob/master/modules/display.c#L8050 | 11:27 |
| freemangordon | https://github.com/sailfishos/mce/blob/master/modules/display.c#L5154 | 11:27 |
| uvos | i strongly doubt that a boot state is needed, what for? because of blanking pause? | 12:05 |
| freemangordon | yes | 12:05 |
| freemangordon | but, it is not that simple | 12:05 |
| uvos | mce should not be a system deamon at all, thats a hangover from fremantle bad arch | 12:05 |
| uvos | it only dose session things and should be started with the session | 12:06 |
| uvos | and should only affect its session, thats the direction im working | 12:06 |
| freemangordon | mce controls display blanking, so you should know when to blank and when not to | 12:06 |
| uvos | this also obviates any problems beacuse mce will only start with the session too | 12:06 |
| freemangordon | how's that? what if we want to display some "session start" vide? | 12:07 |
| freemangordon | *video | 12:07 |
| uvos | start mce after, the fact that mce, for instance, changes the blanking state of other sessions is highly broken | 12:07 |
| uvos | and that other sessions all talk to the same mce | 12:07 |
| uvos | because what it manages is session state, not system state really. | 12:07 |
| freemangordon | honestly, I don;t understand why do you think mobile phone shall act as a workstation | 12:08 |
| freemangordon | this multisession thingie brings absolutely nothing to improve UX | 12:08 |
| uvos | ofc it dose | 12:09 |
| freemangordon | it just makes things overcomplicated without any gain I can see | 12:09 |
| freemangordon | also, adding one more module does not stop mce from being whatever you like | 12:09 |
| freemangordon | just din't load it, right? | 12:09 |
| uvos | 1. sane interoperatbility with other uis (you can install hildon and plamo at the same time for instance) giveing user choice. 2. security, currently many things on leste run with root permissions that realy dont need to. 3. mapphones are transforming devices, they DO turn into workstations on demand, | 12:10 |
| freemangordon | in leste there wil never be multisession stuff, as long as it depends on my opinion | 12:10 |
| freemangordon | so, leste *is* hildon more or less, amd all daemons shall support hildon, in the first place | 12:11 |
| freemangordon | *and | 12:11 |
| freemangordon | everything else is not mission critical | 12:11 |
| uvos | leste should not exist imo | 12:11 |
| freemangordon | then I wonder what do you do on the channel | 12:11 |
| uvos | idealy it would just be hildon-session and be a part of debian/devuan whatever normal distro | 12:11 |
| uvos | this means dealing with sessions | 12:12 |
| freemangordon | how feasible do yo think this is? | 12:12 |
| uvos | so that installing leste dosent break the whole system | 12:12 |
| freemangordon | in 10 years? ... maybe | 12:12 |
| uvos | pretty feasible imo | 12:12 |
| freemangordon | no, it tooks years to push a single patch in distros, take my glib patch for example | 12:12 |
| freemangordon | and they constantly remove things | 12:13 |
| freemangordon | we simply don;t have the manpower to play that gamne | 12:13 |
| freemangordon | *game | 12:13 |
| freemangordon | either we are distro or we stop doing anything as it does not make sence | 12:13 |
| uvos | your optinon not mine | 12:13 |
| freemangordon | efforts were done back then by way more powerful players that 3 of us to push hildon in debian | 12:14 |
| freemangordon | fail | 12:14 |
| uvos | if these efforts where as uncompromizing wrt functionaltiy as you sure | 12:14 |
| norayr | there was someone who became a pmos maintainer for hildon. i think we all want hildon to work on as many distros as possible, we'd like it to be in mobian and maybe debian as well. | 12:14 |
| freemangordon | sure, because I want a mobile I can count on | 12:14 |
| uvos | i can count on means 100% fremantle parity and behavior in detail | 12:15 |
| freemangordon | norayr: hildon itself works whatever you compile it | 12:15 |
| uvos | ofc that makes everything way more work | 12:15 |
| freemangordon | the point is that hildon as such does not make a mobile OS | 12:15 |
| freemangordon | and *mobile* support is non-existent in big distros | 12:15 |
| freemangordon | that's why we do what we do | 12:16 |
| uvos | the other mobile uis work fine as sessions, sure they still have lots of stuff forked to but they actively work on becomeing closer to being "simple desktops" | 12:16 |
| uvos | wayland helps alot with that ofc | 12:16 |
| freemangordon | ah, yeah, the next best thing | 12:17 |
| uvos | mce really is only a thing beacuse hildon is a wm | 12:17 |
| freemangordon | how exactly mutisession helps? | 12:17 |
| uvos | hmm? | 12:17 |
| uvos | how wayland helps mutisession? | 12:17 |
| freemangordon | UX wise | 12:18 |
| freemangordon | we were discussion multisession, you brought WL to the table | 12:18 |
| freemangordon | so, ignore WL | 12:18 |
| uvos | i awnsered this question | 12:18 |
| uvos | "1. sane interoperatbility with other uis (you can install hildon and plamo at the same time for instance) giveing user choice. 2. security, currently many things on leste run with root permissions that realy dont need to. 3. mapphones are transforming devices, they DO turn into workstations on demand" | 12:18 |
| uvos | point 1 is also sane install process on manny devices | 12:19 |
| freemangordon | pushing months of effort in multisession to cover some corner usecaes when we miss basic functionality is not really helpful for the project | 12:19 |
| freemangordon | I care no for other UIs, so this is not an argument | 12:19 |
| freemangordon | like, it is good to have | 12:19 |
| freemangordon | but if we don;t have it, well... | 12:19 |
| uvos | but being a regular xdg session would free lots of time to | 12:19 |
| uvos | because we are currently stuck messing with hw support for a handfull of devices | 12:20 |
| freemangordon | how exactly, if we speek in terms of the boot process. how do you imagine managing the boot session in terms of visual lock, for example? | 12:20 |
| uvos | while really we should focus on our session and pool the hw stuf with the other uis by being part of some distro | 12:20 |
| freemangordon | agreed on the HW part | 12:21 |
| freemangordon | but that's not what I am talking about | 12:21 |
| uvos | but that requires us to be a sane session | 12:21 |
| freemangordon | ok, what about doing it like this: | 12:21 |
| uvos | anyhow so boot with lock | 12:21 |
| uvos | 1. phone boots, nodm runs, our session is default, we run tklock as normal | 12:22 |
| uvos | thats how other uis work... | 12:22 |
| freemangordon | lets have some meeting or, dunno, each of us to draft how s/he thinks boot process shall look like | 12:22 |
| Wizzup | so ofonod would not run until our session starts? | 12:22 |
| freemangordon | and then discuss and have a clear picture what we shall aim for | 12:22 |
| uvos | Wizzup: maybe sure, that would not be our choice but the distros | 12:22 |
| Wizzup | I don't think that's a maybe, I think that's important, also wrt emergency calls | 12:23 |
| uvos | but ofono running only when our session starts is no problem | 12:23 |
| Wizzup | either that or the login manager has to handle calls | 12:23 |
| uvos | as we would reccomend nodm as default | 12:23 |
| norayr | this is also why open nource and democratically governed projects are way better than proprietary ones? nokia or some company would need a product at the market asap, and they would be (and they was) ok with lots of dirty things, they even forked debian, without caring to be at least compatible with sarge repos. and then people were 'porting' mcabber like programs to maemo. | 12:23 |
| uvos | nodm just starts the default session and dose nothing else | 12:23 |
| uvos | Wizzup: emergency calls would work as before, currently you cant place one untill our "session" starts anyhow | 12:24 |
| uvos | its just that session has leaks all over the place is the difference | 12:24 |
| uvos | now if the user decides to install some other dm other than nodm thats his problem | 12:24 |
| Wizzup | if we require mce to be part of our session, it still needs to collaborate with us, no? | 12:25 |
| freemangordon | uvos: even in that scenario, mce should know when the init is done | 12:25 |
| Wizzup | this feels quite fringe to me atm | 12:25 |
| uvos | i dont see why | 12:25 |
| uvos | @mce | 12:25 |
| uvos | it starts at almost the same time as hildon then | 12:25 |
| freemangordon | to not blank the screen before it is needed | 12:25 |
| uvos | why would need to know anyhtin | 12:25 |
| Wizzup | since mce is -our- project | 12:25 |
| uvos | g | 12:26 |
| uvos | if you want to display some video on session start, fine | 12:26 |
| uvos | run a window that blocks mces balnking via the inhibit dbus interface | 12:26 |
| uvos | no need to invent some new global state | 12:26 |
| freemangordon | no, I don;t want it to blank the screen before DE has finished whatever it has to in its startup | 12:26 |
| uvos | a problem in theory, but not in pactice | 12:27 |
| freemangordon | no, sorry, that's overkill | 12:27 |
| uvos | whats happeing that the startup of the de is longer than the blaning interval? | 12:27 |
| freemangordon | this is the problem in practice and I will capture a video to show you | 12:27 |
| uvos | this is not caused by what you think | 12:27 |
| freemangordon | exactly this is the point | 12:27 |
| uvos | mce has 25 sec on the timer | 12:27 |
| uvos | when your blank occures | 12:28 |
| uvos | something is triggerin an immidate blank either external or some missbhavieing module | 12:28 |
| uvos | this is not related | 12:28 |
| Wizzup | I think we need to strike a balance between how much effort we put in 'making everything fdo compliant' and actually getting something that works well. from my perspective getting something that works well and is single session is a good point to start looking at multi session behaviour, because we have a known-good state | 12:28 |
| freemangordon | if you set blanking to 10 seconds, it blanks 10 seconds after dsme reports "init finished" | 12:28 |
| Wizzup | (and we're not at that state yet imho) | 12:28 |
| freemangordon | agree | 12:29 |
| uvos | right because mce is a system deamon its starting to early | 12:29 |
| uvos | thats why i was talking about where im taking it | 12:29 |
| uvos | (makeing it session only...) | 12:29 |
| freemangordon | sure, but until we have multisession we shall fix that | 12:29 |
| freemangordon | and I think I proposed the least intrusive way | 12:30 |
| freemangordon | whi, BTW, will continue work even after we have multisesson | 12:30 |
| freemangordon | *which | 12:30 |
| uvos | the least intrusive way is just to write a xessesion script that kicks mce | 12:30 |
| uvos | no need for any interfaces or modes | 12:30 |
| freemangordon | not now | 12:30 |
| freemangordon | if ever I am going to | 12:31 |
| uvos | no i mean just restart mces timer | 12:31 |
| uvos | as the first xsession script | 12:31 |
| uvos | you can just do that with no change to mce | 12:32 |
| uvos | also btw | 12:32 |
| freemangordon | and what if it takes 120s for h-d to start? | 12:32 |
| uvos | something external to mce is missbehaveing in your bootup log | 12:32 |
| uvos | and its not in mine so im gona say systemui | 12:32 |
| freemangordon | could you elaborate? | 12:33 |
| uvos | something is contiously checking display state and forceing it on via dbus.. | 12:33 |
| uvos | so yeah | 12:33 |
| uvos | and the blank there as i said | 12:33 |
| uvos | is not beacuse of the inactivity timer | 12:33 |
| uvos | its something else | 12:33 |
| freemangordon | what else? | 12:33 |
| uvos | idk | 12:33 |
| uvos | but the timer never expires | 12:33 |
| freemangordon | ok, but this happens only lemme provide you with some extended logs | 12:34 |
| freemangordon | I put some traces | 12:34 |
| freemangordon | https://pastebin.com/qU5K1iXp | 12:34 |
| uvos | Sep 21 12:02:55 localhost mce[2733]: inactivity: device inactivity timeout 10 | 12:35 |
| freemangordon | display_state_trigger 1 | 12:35 |
| uvos | Sep 21 12:03:00 localhost mce[2733]: tklock.c: opening tklock mode 1 | 12:35 |
| freemangordon | yes | 12:35 |
| uvos | the display begins blaning 5 sec | 12:35 |
| uvos | after the timer is reset to 10 | 12:35 |
| uvos | its not the timer | 12:36 |
| uvos | the other log is even clearer | 12:36 |
| freemangordon | sure it is not | 12:36 |
| uvos | beacuse you had a 30s timer | 12:36 |
| freemangordon | mce tries to tklock | 12:36 |
| uvos | sure | 12:36 |
| uvos | by why | 12:36 |
| uvos | but | 12:36 |
| uvos | this is the bug | 12:36 |
| uvos | not something else | 12:36 |
| freemangordon | with bootmode_state, tklock will know what happens: https://github.com/maemo-leste/mce/blob/59d0d5e18a0b5df5ca752f5888b4207789a4d85b/src/modules/lock-tklock.c#L1110 | 12:38 |
| uvos | sure | 12:38 |
| uvos | but thats peppering over a problem | 12:38 |
| uvos | *papering | 12:38 |
| uvos | there is no reason for mce to trigger a lock at that time | 12:38 |
| uvos | it dose so erroniously | 12:38 |
| freemangordon | as I said, mce shall not touch the display until DE had started | 12:39 |
| uvos | it should not, with no requirement for any bootstate | 12:39 |
| uvos | as mce has no reason to trigger a lock until the timer expires is the point | 12:39 |
| norayr | sicelo, btw i forgot to tell you one very bad thing about phosh: you cannot run pidgin on it, as well as any multiwindow program: it gives the focus only to the last opened window of that program and other windows are not responsive at all. | 12:39 |
| freemangordon | but, it does now because it has no clue if DE has started ot not | 12:39 |
| uvos | no | 12:40 |
| freemangordon | anyway, lunch time, ttyl | 12:40 |
| uvos | its not preventing it becasue it has no clue | 12:40 |
| uvos | the trigger is still comeing from somehwere | 12:40 |
| uvos | i also wonder whats spamming mce with display reqests... | 12:41 |
| freemangordon | ok, I will put traces on the pipe | 12:41 |
| freemangordon | but, that will not solve the other issue mce shall wait for DE ti signal 'ready' before doing any blanking or whatever | 12:42 |
| freemangordon | multisession or not | 12:42 |
| uvos | i dont see that as nessecary at all really | 12:42 |
| uvos | its a solution in search of a problem | 12:43 |
| freemangordon | because you have determined startup procedure that way | 12:43 |
| freemangordon | we may want to switch to parallel bot at some point | 12:43 |
| freemangordon | *boot | 12:43 |
| uvos | so | 12:43 |
| freemangordon | and startup times (esp on a fast device) will be very short | 12:43 |
| uvos | great | 12:43 |
| uvos | even less of an issue then | 12:43 |
| freemangordon | no, sorry | 12:44 |
| uvos | unless you mean to say "mce might start even earlier relatvie to other suff then" well depdens helps with that. | 12:44 |
| freemangordon | mce shall have deterministic, not random behaviour when it comes to when to start blanking it terms of startup | 12:46 |
| freemangordon | so, blanking period shall start after DE is ready | 12:47 |
| freemangordon | no way to achieve that without signal from DE | 12:47 |
| freemangordon | so, I am going to write that module. ofc, if you know better/cheaper way to achieve, please share | 12:48 |
| uvos | there needent be a difference significant to care about, and a bit of randomness is no problem as long as it is a small time compeared to the overall blank interval | 12:48 |
| uvos | besides the blaning interval was totaly broken on fremantle an no one seam to notice | 12:49 |
| freemangordon | sorry, lunch | 12:49 |
| uvos | (the tlock issue wasent the only one....) | 12:49 |
| freemangordon | ttyl | 12:49 |
| freemangordon | I'll capture a video later on to show you why I think UX is broken if we don't serialize | 12:51 |
| freemangordon | bbl | 12:51 |
| freemangordon | uvos: http://46.249.74.23/leste/20220921_001.mp4 | 14:04 |
| uvos | freemangordon: the video dosent show anything | 14:42 |
| uvos | freemangordon: it shows the same thing as the log | 14:42 |
| uvos | freemangordon: some interaction with systemui/tklock causes mce to turn off the display, this interaction is a bug | 14:43 |
| uvos | its not related to when hildon starts at all | 14:43 |
| uvos | or the timeout or so on | 14:43 |
| uvos | we need to figure out what is (explicitly) telling mce to blank | 14:44 |
| uvos | disregarding if its nessecary for other reasons, papering over the problem by adding a global mode that makes mce happen to ignore this request is not the solution | 14:46 |
| freemangordon | ok, I'll put additional trtaces | 14:59 |
| uvos | if id have to gues | 15:04 |
| uvos | id say its because there blanking timers in mce tkloc.c | 15:05 |
| uvos | that do sepcial timeouts for vtklock | 15:05 |
| uvos | but | 15:05 |
| uvos | usualy tklock blocks these with dnd | 15:05 |
| uvos | so they would seam vestigial | 15:06 |
| norayr | i have 'sapwood-server' MUST be started before applications' messages if i run pidgin or other gtk apps from console. | 15:09 |
| norayr | what does that mean? can i start that sapwood? | 15:09 |
| uvos | norayr: whats your DISPLAY? | 15:09 |
| norayr | oh i see sapwood server is started | 15:10 |
| norayr | uvos - right question. i tried to run pidgin with x forwarding now to reconfigure. | 15:10 |
| norayr | so it's only when the display is not local? | 15:10 |
| uvos | sapwood breaks x remoteing | 15:11 |
| norayr | then other question - which is the default gtk theme? alpha, default, raleigh? | 15:11 |
| uvos | your DSIPLAY needs to be :0.0 and nothing else | 15:12 |
| norayr | i'd like to change it temporarily with gtk-chtheme because this theme doesn't draw some things in pidgin. some edit boxes. | 15:12 |
| uvos | yes also not :0 | 15:12 |
| norayr | interesting. | 15:12 |
| uvos | there is a terrible bug somwhere | 15:12 |
| uvos | where something dosent know zaphodhead is a thing | 15:12 |
| uvos | and :0.0 and :0 are aliases | 15:12 |
| norayr | or which theme should i install temporarily? | 15:14 |
| norayr | which is used now? i cannot see even that by running gtk-chtheme. | 15:14 |
| uvos | im not sure what your asking about themes | 15:14 |
| norayr | hildon draws everything on black, right? | 15:16 |
| norayr | so that's some maemo gtk theme. how is it called? | 15:16 |
| rafael2k_ | there is a way to call gtk apps with different theme | 16:33 |
| rafael2k_ | I do this for qcam and other apps which misbehave with default maemo theme | 16:33 |
| rafael2k_ | for qt stuff at least, I need to use "-platform xcb -style=fusion" | 16:34 |
| rafael2k_ | otherwise I get some black on black things | 16:35 |
| freemangordon | uvos: which pipe shall I watch? | 16:43 |
| freemangordon | display_brightness_pipe? | 16:44 |
| freemangordon | I guess this comes from alarm_state in tklock | 16:50 |
| freemangordon | also, I still don;t understand who is going to display alarms if there is no session (like when we are in charge mode) | 16:52 |
| freemangordon | but that's anotehr story | 16:52 |
| norayr | rafael2k_: how is the state of libcamera? | 16:58 |
| norayr | do you also consider other devices, not only pinephone? | 16:59 |
| norayr | will we have camera working on pinephone? | 16:59 |
| norayr | will we have camera working on droid? | 16:59 |
| Wizzup | eventually, yes | 17:00 |
| norayr | eventually i know, and i believe! | 17:00 |
| norayr | (: | 17:00 |
| norayr | it's interesting how is the state, maybe already we can use some cam software (not megapixels), and i don't know? | 17:01 |
| norayr | rafael2k_: i remember i was doing this, yes, running with different gtk themes. i should have scripts somewhere... | 17:01 |
| norayr | oh i was exporting like this:, and i had several different gtkrc files: export GTK2_RC_FILES=~/gtkrc_grqi-2 | 17:03 |
| uvos | freemangordon: charge mode simply exits to a script on alarm | 17:05 |
| uvos | this script can do anything | 17:05 |
| uvos | rn it switches runlevels to boot to hildon | 17:06 |
| uvos | conciveably it could start some session too | 17:06 |
| uvos | freemangordon: so 2 things in your log looks really off | 17:09 |
| uvos | freemangordon: one is someone is hammering display_status_get_dbus_cb via dbus | 17:09 |
| freemangordon | I will have extended traces in 2-3 minutes | 17:10 |
| rafael2k | norayr: status is "works for me" state, as nobody else tested | 17:10 |
| freemangordon | building ATM | 17:10 |
| uvos | and the other thing is after Submode changed to 513 someone requests display off via display_state_pipe | 17:11 |
| rafael2k | norayr: the idea on using libcamera is exactly for having a low-level which can support multiple hardware | 17:11 |
| uvos | someone is also hammering display on at the same time | 17:11 |
| uvos | (probubly dbus it comes right agter display_status_get_dbus_cb)\ | 17:12 |
| uvos | (probubly dbus it comes right agter display_status_get_dbus_cb) | 17:12 |
| freemangordon | I don't have any idea how to check who calls that | 17:12 |
| rafael2k | need to leave now, but anyone wants to discuss the the camera architecture on maemo, we can talk tomorrow | 17:12 |
| freemangordon | (dbus call I mean) | 17:12 |
| rafael2k | btw, camera is working on pinephone, we just don't have proper userland support yet | 17:13 |
| uvos | well some other process is calling display_status_get_dbus_cb and then the display on req several times per second in your log | 17:13 |
| uvos | thats.. not great even if its not the cause of the current problem | 17:13 |
| uvos | pretty sure its systemui as it dosent occure in my log | 17:14 |
| freemangordon | several times per second? | 17:15 |
| uvos | yes look at 9:12:58 in your first log | 17:15 |
| uvos | but it also continues elsewhere | 17:16 |
| uvos | anyhow it stoppes before the real problem starts | 17:17 |
| uvos | so its unlikely to be related | 17:17 |
| freemangordon | hmm, right | 17:19 |
| freemangordon | uvos: we geg device_inactive_trigger in display.c | 17:22 |
| freemangordon | *get | 17:22 |
| freemangordon | hmm, maybe this happens after timeout | 17:23 |
| freemangordon | lemme pastebin the log | 17:23 |
| uvos | so who calles it | 17:23 |
| uvos | clearly not inactivity_timeout_cb | 17:23 |
| freemangordon | https://pastebin.com/iAu5mS3z | 17:24 |
| uvos | so the only users of device_inactive_pipe are: camera (not loaded), inactivity-inhibit (dosent call inactive), lock-generic (not loaded), battery-upower (hmm), inactivity (not it), lock-tklock (this one maybe), event-input | 17:25 |
| uvos | cant be tklock.c either | 17:26 |
| freemangordon | looks like inactivity | 17:26 |
| uvos | cant be battery-upower | 17:26 |
| freemangordon | Sep 21 18:16:11 localhost mce[2726]: device_inactive_trigger device_inactive 1 !!!!!! | 17:27 |
| freemangordon | Sep 21 18:15:42 localhost mce[2726]: inactivity: device inactivity timeout 30 | 17:27 |
| freemangordon | 30 seconds | 17:27 |
| uvos | dosen jive with your logs | 17:28 |
| uvos | Sep 21 18:21:37 localhost mce[2726]: inactivity: device inactivity timeout 30 | 17:28 |
| uvos | Sep 21 18:21:37 localhost mce[2726]: display: Sending display status: dimmed | 17:28 |
| uvos | < 1s | 17:28 |
| freemangordon | this is after that | 17:28 |
| uvos | sure if you wait 30s it will dim | 17:28 |
| freemangordon | look at 18:16:11 | 17:29 |
| uvos | but thats not the problem here, its that it dims way before that | 17:29 |
| freemangordon | yes, it dims @ 18:15:42 | 17:29 |
| freemangordon | ugh, I got lost | 17:30 |
| freemangordon | it dims @ 18:16:11 | 17:30 |
| freemangordon | maybe as a result of "Received init done notification" | 17:31 |
| uvos | it dimms at 18:16:11 beause the timer expired | 17:31 |
| freemangordon | or maybe because the last timer reset was 30 seconds ago | 17:31 |
| freemangordon | yes | 17:31 |
| uvos | but that wasent in the other logs | 17:32 |
| freemangordon | but by that time it still boots | 17:32 |
| freemangordon | maybe traces change some timing | 17:32 |
| uvos | nah we where just looking at the wrong event | 17:33 |
| freemangordon | could be | 17:33 |
| freemangordon | where is the correct one? | 17:33 |
| uvos | no idea why it dimms later | 17:33 |
| uvos | yeah the other logs have just one dimmed event | 17:34 |
| uvos | and its right after a timer reset | 17:34 |
| uvos | ah no | 17:34 |
| uvos | i get it | 17:34 |
| uvos | it is the timer | 17:34 |
| freemangordon | mhm | 17:34 |
| uvos | even in the other logs | 17:35 |
| freemangordon | "Sending inactivity status: inactive" | 17:35 |
| uvos | because the dim has its own timer too | 17:35 |
| uvos | so it comes 2 or so s after the timer expires | 17:35 |
| uvos | by that time something reset the timer again | 17:35 |
| uvos | but that should cancle the dim | 17:35 |
| uvos | so its the same bug as your other bug | 17:35 |
| freemangordon | is it possible it the the same bug | 17:35 |
| uvos | yes | 17:35 |
| freemangordon | right | 17:35 |
| uvos | alrighty then | 17:36 |
| freemangordon | ok, please fix as you have time, I will test and will see if we still need startup module | 17:36 |
| uvos | probubly yes | 17:37 |
| uvos | for 10s | 17:37 |
| uvos | unfortinatly for now | 17:37 |
| freemangordon | I will make it listen for h-d startup event | 17:37 |
| uvos | no | 17:37 |
| freemangordon | this module will be specific to hildon | 17:37 |
| uvos | sure but | 17:37 |
| uvos | maybe a xsession script that runs last is sufficant? it could be shipped with mce and would work anyhere | 17:38 |
| freemangordon | it is the same | 17:38 |
| freemangordon | sec | 17:38 |
| uvos | also dont we have some init script that waits for hildon | 17:39 |
| uvos | whats that for anyhow? | 17:39 |
| uvos | its just some hack with a sleep | 17:39 |
| freemangordon | wait a minute | 17:39 |
| freemangordon | see Xsession.post/hildon-desktop-wait | 17:40 |
| freemangordon | this is that "ready" signal I am talking about | 17:40 |
| freemangordon | exactly what you said | 17:40 |
| uvos | right ok | 17:40 |
| freemangordon | it is not signalled by h-d itself | 17:40 |
| uvos | fine | 17:40 |
| freemangordon | great that we have a deal :D | 17:41 |
| uvos | maybe also add a fallback that exits booting mode after some time | 17:41 |
| freemangordon | sure | 17:41 |
| uvos | (long ofc) | 17:41 |
| freemangordon | right | 17:41 |
| freemangordon | actually it is Xsession.post/21hildon-desktop-wait | 17:42 |
| freemangordon | but that's another story | 17:42 |
| uvos | oh also dont re-add the signal to display.c | 17:43 |
| uvos | it belongs in inactivity.c now | 17:43 |
| freemangordon | sure | 17:44 |
| freemangordon | but, I'll re-add to tklock | 17:44 |
| uvos | uh | 17:44 |
| freemangordon | well, ok, will see | 17:44 |
| freemangordon | it might not be needed | 17:44 |
| uvos | that seams like the wrong place | 17:44 |
| freemangordon | ok | 17:45 |
| freemangordon | but I need that dim bug fixed first | 17:45 |
| uvos | sure | 17:45 |
| freemangordon | I won;t have reliable test case otherwise | 17:45 |
| freemangordon | ttyl | 17:46 |
| sicelo | Maemo Leste | 21:52 |
| sicelo | norayr: about phosh ... you can submit an issue in their bugtracker. they're very welcoming | 21:57 |
| norayr | it's on gnome gitlab right? | 21:58 |
| norayr | i commited something to squeekboard about a year ago. | 21:59 |
| sicelo | i think so, yes. they have a matrix room too | 21:59 |
| norayr | sicelo, i had an impression it is such a limitation they won't be able to overcome. | 22:00 |
| sicelo | what makes you think so? | 22:01 |
| norayr | i don't know, the talk in pmos room probably. they didn't give me hope it is possible to overcome the focus issue. | 22:02 |
| norayr | i'll try to open the issue, thank you for suggestion. | 22:02 |
| norayr | it didn't come to my mind. | 22:02 |
| sicelo | pmOS != phosh. pmOS are just consumers | 22:04 |
| sicelo | i don't use pidgin on my desktop, but i don't think wayland and/or sway (wlroots) has a special reason for multi-window applications to have issues. phosh is wlroots based, so i doubt there are real reasons why they couldn't support multi-window | 22:10 |
| sicelo | they might choose not to, but i guess that's not a technical limitation | 22:10 |
| sicelo | s/that's not/that would not be/ | 22:10 |
| uvos | im probubly not totaly up to date on pidigin development, but isent pidgin still gtk2/x11 only? ie it runs in xwayland on wayland display servers? | 22:27 |
| uvos | if so i would not be terribly suprized if phosh devs have more serious issues to work on than fixing a multi-window x11 app | 22:28 |
| * numonyx on pidgin+sway. no window focus issue | 23:01 | |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!