| uvos | the backend button should def not go into settings imo | 00:24 |
|---|---|---|
| uvos | its maybe sligtly missnamed | 00:24 |
| uvos | it really means potocoll, and the hope is that you will eventually be able to choose gsm/voip/skype/telegram/etc here to place your call | 00:25 |
| uvos | settings is, imo, to to rigid for something that is expected to possibly vary with every call | 00:25 |
| uvos | also there is sufficent room | 00:27 |
| uvos | there is no need to get rid of anything | 00:27 |
| uvos | so i would do this: | 00:28 |
| uvos | ========== < | 00:30 |
| uvos | ============= < | 1 | 2 | 3 | 00:30 |
| uvos | contacts | 4 | 5 | 6 | 00:30 |
| uvos | recent | 7 | 8 | 9 | 00:30 |
| uvos | call cancle | * | 0 | # | 00:30 |
| uvos | or maybe flipped | 00:31 |
| uvos | | 1 | 2 | 3 | ============= < | 00:31 |
| uvos | | 4 | 5 | 6 | contacts | 00:31 |
| uvos | | 7 | 8 | 9 | recent | 00:31 |
| uvos | | * | 0 | # | call cancle | 00:31 |
| uvos | since call and contacts are going to be the most used buttons, and should be closest to the thumb | 00:32 |
| Wizzup | yes, backend should not be in settings | 04:22 |
| Wizzup | with tp we'll have many backends | 04:45 |
| Wizzup | uvos__: do you think it's worth adding the mz617 hacks to our experimental or devel kernel? | 04:45 |
| uvos__ | Wizzup: thatswhz i | 08:08 |
| uvos__ | upps | 08:08 |
| uvos__ | Wizzup: thats why i rebased the kernel on 6.6 | 08:08 |
| uvos__ | but its currently no use untill the omap-dai is fixed | 08:09 |
| Wizzup | ok | 08:18 |
| nela | someone was tracking down the IR TX issue on N900 and found the timing issues, did we ever get to the end of it? | 09:05 |
| nela | also I now acquired a second worse condition device for debugging purposes and I will solder a UART header to it shortly | 09:06 |
| freemangordon | nela: see https://patchwork.kernel.org/project/linux-media/patch/1696501739-29861-1-git-send-email-ivo.g.dimitrov.75@gmail.com/ and https://patchwork.kernel.org/project/linux-media/patch/1560b474f7d426bc77100665c14c3a29c3af3e75.1697193646.git.sean@mess.org/ | 09:26 |
| Guest224 | dear developers Leste wiki has error at PP: Keyboard, Yes, When a PP keyboard is connected, it works out-of-the-box | 10:30 |
| Guest224 | it should be this way: Keyboard, WIP, When a PP keyboard is connected, all exept third level of first row | 10:32 |
| Guest224 | It had not be working right way in any stable version. | 10:33 |
| Guest224 | you find problem quite fast when writing with PP keyboard: setxkbmap -query | grep model | 10:35 |
| Guest224 | solution is in that link I put yesterday, but it should merge to next version of Leste. | 10:40 |
| Guest224 | or is it coming in next version already? | 10:42 |
| uvos | freemangordon: sure that fixes the issue with ir-tx | 16:40 |
| uvos | but is the underlying issue of the delay taking longer than expected still there | 16:40 |
| uvos | if so i suspect it might be the cause for bluetooth audio being semi-broken on d4 | 16:41 |
| uvos | (it faces fairly constant ~100ms clicks where something is unable to keep the stream going, even when pm states are disabled) | 16:42 |
| uvos | us | 16:42 |
| sicelo | arno11 ... i did test the transitions.ini. all is well indeed. just one nitpick - when in the application list, not blanking/dimming the wallpaper makes things seem confusing/cluttered | 19:13 |
| arno11 | sicelo: yes, need a bit of work for this | 19:13 |
| arno11 | sicelo: i have another transitions.ini file wich is faster (but still the confusing app list) | 19:15 |
| arno11 | *btw | 19:15 |
| arno11 | uvos: sicelo: https://ibb.co/MpBhkRR | 19:16 |
| arno11 | this is the best result i have ATM | 19:16 |
| arno11 | still using hbox (vbox is tricky to use with the keypad) | 19:17 |
| arno11 | but user friendly even with big fingers IMO | 19:18 |
| sicelo | this looks good! i think you can bring Recent to the bottom as well, and have three buttons on that bottom row | 19:18 |
| sicelo | but i don't see 'Cancel' ;p | 19:18 |
| arno11 | i removed it lol | 19:19 |
| arno11 | but i can add it again | 19:19 |
| arno11 | (if uvos is hangry) | 19:20 |
| sicelo | i don't think it'll be approved :p | 19:20 |
| arno11 | *angry | 19:20 |
| arno11 | yes indeed :p | 19:20 |
| arno11 | maybe i can add 'recent' at the bottom row and add 'cancel' on the top one ? | 19:22 |
| arno11 | *instead of 'recent' | 19:22 |
| sicelo | i'm quite sure they want Cancel to be at the bottom ... presumably to close the application easily, even in portrait mode | 19:31 |
| arno11 | ok | 19:33 |
| uvos | pretty mutch exactly correct | 19:34 |
| arno11 | so call, contacts, cancel | 19:34 |
| uvos | i also really dont like this layout for another reason: its too different to the portrait one | 19:34 |
| uvos | the relative possitioning of buttons should stay the as mutch the same as possible | 19:34 |
| uvos | to avoid too mutch user suprise | 19:34 |
| arno11 | agreed but dealing with vbox columns is tricky | 19:35 |
| arno11 | *with the keypad | 19:35 |
| uvos | hmm | 19:36 |
| uvos | the keypad is one widget anyhow | 19:36 |
| uvos | so just have a everything in a vbox inside a hbox that contains just the vbox in portait | 19:36 |
| uvos | and remove the keypad from the vbox and add it to the hbox where the vbox is also in when switching to landscape | 19:37 |
| uvos | or rather when switching to a window that too small for the portrait layout | 19:37 |
| arno11 | vbox inside a hbox is what i'm trying to use ATM with no success | 19:39 |
| arno11 | question of time :p | 19:39 |
| uvos | ok, not sure what issues would crop up there | 19:39 |
| uvos | but its been a whlile since i wrote a gtk2 ui layout | 19:39 |
| uvos | oh btw | 19:44 |
| uvos | i would recommend "scrot" to take screenshots over ssh | 19:44 |
| uvos | mutch less work than makeing a photo | 19:44 |
| arno11 | thx for the tip | 19:51 |
| arno11 | question of POV but i think the last example is not so different from the portrait mode: in every cases we have to add buttons on the right/left/bottom/top anyway | 20:15 |
| freemangordon | uvos: yes, and unfortunately I have no idea what the reason could be. However, seems to be process priority/scheduler related, like, on omap4 with proper priority latency is low. Keep in mind the shortest measurable period is ~30us, because system timer is running @ 32kHz, so maybe scheduler has no option when we have 3-4 high-priority tasks but to delay each task re-activation with couple of 30us periods | 21:20 |
| uvos | freemangordon: if you think its related to scheduler behavior maybe we should try a different one than cfs, like pds or bmq or the like, those are mostly more optimized for interactive systems anyhow | 22:05 |
| freemangordon | uvos: if you give me some hints I can try | 22:32 |
| freemangordon | but yeah, seems scheduler related | 22:33 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!