| uvos | hmm | 00:29 |
|---|---|---|
| uvos | i cant seam to flash the n900 | 00:29 |
| uvos | so ./0xFFFF -m u-boot-2013.04-2-with-freemantle-kern.bin -f | 00:29 |
| uvos | the device is off and i connected it to usb | 00:29 |
| uvos | "Found USB device: RX-51/RM-680/RM-696 (0x421:0x106) in Cold flashing mode" | 00:29 |
| uvos | and the device starts | 00:30 |
| uvos | "Switching to NOLO mode..." | 00:30 |
| uvos | "Waiting for USB device..." | 00:30 |
| uvos | "Error: Device detection failed" | 00:30 |
| uvos | and then 0xFFFF goes back to waiting for device | 00:31 |
| uvos | ad infinitum | 00:31 |
| uvos | device just ends up sitting at uboot prompt | 00:32 |
| Wizzup | uvos: did you compile your own 0xFFFF | 00:37 |
| uvos | Wizzup: no i used the one linked in the wiki | 00:38 |
| Wizzup | uvos: ok, so it's not libusb 0.1 compat related then | 00:39 |
| Wizzup | tried a different cable? | 00:39 |
| Wizzup | or maybe running as root? | 00:39 |
| uvos | its as root | 00:39 |
| uvos | different cable sure | 00:39 |
| uvos | sec | 00:39 |
| uvos | ah i got it work | 00:41 |
| uvos | was low voltage i gues | 00:41 |
| uvos | (it worked with external power supply) | 00:42 |
| Wizzup | ok | 00:42 |
| Wizzup | btw, with the new libicd-network-wpasupplicant I do not get scan failures anymore | 00:43 |
| Wizzup | I was seeing them with the previous -devel version | 00:43 |
| Wizzup | not sure if it was just me or not, but if anyone can confirm that's nice | 00:43 |
| uvos | fremantle hildon-desktop absolutly has the same bug with the app launcher | 00:43 |
| Wizzup | heh | 00:44 |
| * Wizzup zz | 00:50 | |
| Daanct12 | Wizzup, regarding the volume key | 04:36 |
| Daanct12 | I noticed that vol up and down are registered as F7 and F8 | 04:36 |
| Daanct12 | Maybe that's the reason why the volume bar doesn't work? | 04:37 |
| parazyd | freemangordon: Managed to move connui stuff to stable last night | 08:22 |
| parazyd | Moved everything that made sense btw, and will review and update metapackages today. | 08:22 |
| parazyd | uvos: So we're fine with enabling charge-mode, and fbkeyboard? | 08:22 |
| freemangordon | parazyd: thanks! | 08:24 |
| parazyd | :) | 08:25 |
| uvos | parazyd: yes, fbkeyboard should be activated allready on devel (on bionic only as intended) | 09:37 |
| uvos | Daanct12: no every thing is missing software side the f7 f8 thing is a n900 odity we should probubly change | 09:38 |
| uvos | parazyd: did you read my complaints about irc-this-week btw | 09:38 |
| freemangordon | uvos: why it should change? f7/f8 are not volume keys as one may think, those are multipurpose, context specific keys | 09:39 |
| uvos | freemangordon: they are volume keys, there use elsewhere nonwithstanding. every single other device calls them volume, android vendor kernels call them volume. if we change n900 to fit everything else we save us a lot of headache | 09:41 |
| freemangordon | and then we will have the headache to fix all the code that uses f7/f8, just because android! calls them volume. Good reasoning... | 09:42 |
| uvos | no it goes mucht deper than android | 09:42 |
| uvos | the mainline kernel calls these volume, they are volume on x86 | 09:43 |
| uvos | etc | 09:43 |
| uvos | if you run leste on some random x86 device you want volume to change with the volume buttons on keyboard etc | 09:43 |
| freemangordon | pc 105 keyboard doesn't have volume buttons lst time I chacked | 09:44 |
| freemangordon | *last | 09:44 |
| uvos | yeah the standart ibm layout might not have them but manny manny manny pc keybaords have volume keys | 09:45 |
| uvos | thats what XF86Volume* was added for | 09:45 |
| uvos | f7/f8 is silly nokia Stupidity | 09:46 |
| buZz | XF86AudioRaiseVolume XF86AudioLowerVolume | 09:46 |
| freemangordon | sure, but again, what you call "volume keys" is used for multiple purposes on maemo | 09:46 |
| buZz | those i guess? | 09:46 |
| uvos | freemangordon: so? there primary purpose is volume, they make the moste sense as volume, the camer app zooming or osso-xterm changing font dosent change that | 09:46 |
| freemangordon | no, there is no primary purpose, please get out of your android-ish way of thinking | 09:47 |
| parazyd | uvos: Regarding irc-this-week, you want me to escape that ^A I guess? | 09:47 |
| freemangordon | they are used in xterm(to change the font size) book readiers use them to turn pages, etc,etc | 09:47 |
| uvos | parazyd: yeah i guess, just whatever is nessecary so that file and firefox etc detect the file as plain text | 09:48 |
| parazyd | uvos: okay | 09:48 |
| parazyd | Will do that sometime today | 09:48 |
| uvos | thanks ;) | 09:48 |
| parazyd | I'll clean the file now | 09:48 |
| parazyd | Fix code after I eat something :D | 09:48 |
| uvos | freemangordon: so? the thing is that if you want to enforce your these 2 keys are f7/f8 you will have to change the dts on every device ever just to fit the n900 mold. and users will complain volume odosent change with pc volume keys | 09:49 |
| uvos | that is silly | 09:50 |
| buZz | cant xterm just use XF86AudioRaiseVolume etc? | 09:50 |
| uvos | of course | 09:50 |
| uvos | thats what i am proposing | 09:50 |
| uvos | Wizzup: parazyd ^^^ please comment on this dissagreement.... | 09:50 |
| buZz | and eh, couldnt we just have them -also- be f7/f8 ? | 09:51 |
| uvos | if you dont want to change n900 dts sure | 09:51 |
| parazyd | Aren't Droid4/Bionic and Pinephone doing these as XF86Audio*Volume already? | 09:51 |
| freemangordon | XF86 keys are *already* supported in the relevant parts | 09:51 |
| uvos | but its just a a 4 byre change | 09:51 |
| uvos | parazyd: yes ofc | 09:51 |
| buZz | i think freeman is mostly thinking about all the maemo apps that exist already? | 09:51 |
| freemangordon | yes | 09:51 |
| uvos | parazyd: every pmos device and every android device etc | 09:51 |
| parazyd | So the existing maemo apps work only on N900 | 09:52 |
| uvos | yes | 09:52 |
| freemangordon | vendor kernels is not something we ever wanted to support | 09:52 |
| parazyd | That's funny | 09:52 |
| uvos | freemangordon: its not vendor kernels | 09:52 |
| freemangordon | but what? | 09:52 |
| uvos | freemangordon: its all the mainline kernels for devices | 09:52 |
| parazyd | freemangordon: Mainline | 09:52 |
| uvos | its just what everyone decided these buttons are | 09:52 |
| uvos | and it makes sense users call these "volume buttons" too | 09:53 |
| uvos | WE call them volume buttons in discussions even | 09:53 |
| freemangordon | I understand that argument, but the question is - how you're going to make difference between volume buttons on your hands free and the ones on the device, to not turn page of the book reader you're currently using? | 09:54 |
| freemangordon | I don't want my hands free device to change font size in xterm either | 09:54 |
| freemangordon | the same goes for those fancy multi-media kbds with audio buttons on them | 09:55 |
| freemangordon | Nokia did it that way not because they were stupid, but because they were smart | 09:56 |
| uvos | so for muti-media keyboards i think zooming makes sense. as for hands free, interesting question i wonder how android dose this. | 09:57 |
| buZz | i dont understand the controversy really, doesnt your external keyboard have f7/f8 too? | 09:57 |
| uvos | buZz: sure but other devices dont | 09:57 |
| uvos | and f7/8 is bad ux if volup voldown dosent also work | 09:57 |
| buZz | other devices than keyboards? | 09:57 |
| uvos | yeah like phones | 09:57 |
| freemangordon | buZz: keys on your phone are kbd as well | 09:58 |
| buZz | right | 09:58 |
| freemangordon | the conversation is about hwt keycode shall volume keys generate | 09:58 |
| buZz | so you are saying you want to keep em as f7f8 because you hookup a keyboard to your phone often? | 09:58 |
| freemangordon | *what | 09:58 |
| uvos | no | 09:58 |
| uvos | so n900 dose f7/f8 | 09:58 |
| freemangordon | no, because I hook handsfree often | 09:58 |
| uvos | but every other device dose volup vol down | 09:58 |
| uvos | so you need to reconcile this somehow | 09:59 |
| freemangordon | "every device" is not really an argument, n900 is the best amongst all of them, both HW and SW wise. | 09:59 |
| freemangordon | and please dont bring the number of cores to the table | 10:00 |
| uvos | erm... ok | 10:00 |
| uvos | i hate the keyboard | 10:00 |
| uvos | its too small and close to the display :P | 10:00 |
| freemangordon | then leste is not for you | 10:00 |
| buZz | i find it too small and too thick | 10:00 |
| freemangordon | ah. on n900 | 10:00 |
| freemangordon | well, it was good enough for me 10 years ago... | 10:01 |
| freemangordon | now... I need good light :) | 10:01 |
| uvos | 1000 years ago a slave carrying a letter was good enough | 10:01 |
| uvos | thats hardly a argument | 10:01 |
| freemangordon | the fact that something is newer doesn;t make it any better either | 10:01 |
| uvos | no but thats beside the point | 10:01 |
| uvos | the point is we want leste to just work | 10:02 |
| uvos | on a wide veriaty of devices | 10:02 |
| freemangordon | neither the fact that "everybody does it, but you" | 10:02 |
| buZz | on as many devices as possible, right? | 10:02 |
| uvos | and the f7/f8 thing is an impedement | 10:02 |
| uvos | "everybody does it, but you" is an argument in foss | 10:02 |
| uvos | becaue it fosters interoperability | 10:02 |
| freemangordon | uvos: sure, but that should not be on the price of bad UX | 10:03 |
| freemangordon | and BT controlling bookreader is a bad UX in every book I have around | 10:03 |
| freemangordon | BT HF that is | 10:03 |
| uvos | idk if it is really | 10:03 |
| uvos | so the vol keys inline on a wired headset | 10:04 |
| freemangordon | sure it is, this is real multitaskyng OS | 10:04 |
| parazyd | uvos: Fixed, but I had to reset irc-this-week.txt so it starts from now. The main irc.txt is ok of course. | 10:04 |
| uvos | i think are great if they would do this | 10:04 |
| uvos | parazyd: thanks | 10:04 |
| parazyd | yw | 10:04 |
| freemangordon | so you may have xterm or bookreader or whatever opened while you have a phone conversation | 10:05 |
| freemangordon | you want BT HF volume keys to change the audio volume, not to turn pages | 10:05 |
| uvos | freemangordon: in this case the vol keys on device not chaning the call volume is bad ux..... | 10:05 |
| uvos | in all cases | 10:05 |
| uvos | so you would need some kind of global lock | 10:06 |
| freemangordon | uvos: they do while you;re in a call, IIUC | 10:06 |
| uvos | which is easy to accive via xgrabkey.. | 10:06 |
| uvos | freemangordon: right | 10:06 |
| freemangordon | lets not reinvent the wheel, ok? | 10:06 |
| uvos | freemangordon: im sure thats how it works currently | 10:06 |
| uvos | freemangordon: it needs to block f7/f8 this way | 10:06 |
| parazyd | freemangordon: Keep in mind no device except the N900 does this f7/f8 thing | 10:06 |
| buZz | maybe n810 etc aswell? | 10:07 |
| parazyd | buZz: We don't have an n810 image nor support | 10:07 |
| freemangordon | https://github.com/maemo-leste/maemo-statusmenu-volume/blob/master/src/item.c#L124 | 10:07 |
| uvos | but he is likely right | 10:07 |
| buZz | right, ok | 10:07 |
| freemangordon | parazyd: yes, but that just means we shall remap those somehow as part of HW packages | 10:08 |
| parazyd | freemangordon: Why couldn't we also add XF86AudioRaiseVolume to that grab_keys function? | 10:08 |
| freemangordon | or rather - have this remapping by default, except on N900 | 10:08 |
| buZz | oh, grab 4 keys instead of 2? | 10:08 |
| uvos | or even just change the n900 mapping in kernel.... | 10:08 |
| freemangordon | parazyd: because this grab is in volume applet only | 10:08 |
| freemangordon | uvos: right | 10:09 |
| freemangordon | and then map back to f7/f8, somehow | 10:09 |
| freemangordon | on all devices that is | 10:09 |
| freemangordon | but, this should happen for internal kbd only | 10:09 |
| freemangordon | uvos: can this be done smart enough to remap only internal kbd? | 10:10 |
| uvos | um yeah udev can do that | 10:10 |
| uvos | but i think its a bad idea | 10:10 |
| uvos | also hmm no | 10:10 |
| uvos | i dont think it will work | 10:10 |
| uvos | that only works where the driver exposes hw scancodes | 10:11 |
| uvos | gipo keys (what the volume buttons often are) you cant remap at all | 10:11 |
| freemangordon | well, then we'll have to fix all the other devices, if we want sane UX on them as well | 10:12 |
| uvos | freemangordon: btw talking ux | 10:17 |
| uvos | freemangordon: any idea why scrolling in the app launcher grid is broken | 10:18 |
| uvos | freemangordon: in fremantle even | 10:18 |
| freemangordon | not sure what you mean 'broken' | 10:24 |
| freemangordon | could you explain | 10:24 |
| freemangordon | you mean kinetic scrolling is not smooth? | 10:25 |
| uvos | freemangordon: you scroll, and you let go of it at speed, it should continue scrolling at the speed you left it at | 10:25 |
| uvos | but in reality it just stops | 10:25 |
| uvos | most of the time | 10:25 |
| freemangordon | yeah, right | 10:25 |
| uvos | other times it coniunues scroling very slowly | 10:25 |
| freemangordon | yep, just reproduced | 10:25 |
| uvos | this hapens in freemantle too | 10:25 |
| uvos | *happens | 10:25 |
| freemangordon | :nod: | 10:25 |
| freemangordon | a bug, most-probably | 10:26 |
| freemangordon | will have a look at it, someday | 10:26 |
| uvos | ok | 10:26 |
| freemangordon | shoudl be somehwere in the tidy code | 10:26 |
| Wizzup | Daanct12: that is another reason it might not work, but not the main one | 11:00 |
| * uvos testing https://maedevu.maemo.org/irc-this-week.txt | 11:07 | |
| uvos | works | 11:08 |
| parazyd | uvos: Will you have some time in the afternoon to give me a second pair of eyes on metapackages and perhaps leste-config? | 11:08 |
| uvos | parazyd: sure | 11:08 |
| parazyd | Cool | 11:08 |
| * sicelo keeps wondering if he shouldn't quit Leste because it's based on silly s/w | 11:39 | |
| Wizzup | freemangordon: the f7/f8 handling is not too hard I think | 11:41 |
| parazyd | ? | 11:41 |
| Wizzup | freemangordon: also many oher devices uses other keys than f7/f8 already | 11:42 |
| bencoh | sicelo: wait, what? | 11:42 |
| uvos | its a dig at me | 11:42 |
| uvos | dont mind it | 11:42 |
| Wizzup | parazyd: I do have a n810 btw, but no support | 11:44 |
| Wizzup | I do think the F7/F8 is quite random | 11:45 |
| Wizzup | but don't necessarily have a good solution | 11:46 |
| Wizzup | there are F keys until F20 | 11:49 |
| Wizzup | even more actually it seems | 11:49 |
| uvos | some of those dont work | 11:49 |
| Wizzup | linux/keyboard.h has until K_F245 | 11:49 |
| uvos | any keycode >240 something is impossible to use with x | 11:49 |
| Wizzup | right | 11:52 |
| freemangordon | Wizzup: could you elaborate on the "fix", I am not quite sure I understand | 12:02 |
| Wizzup | freemangordon: I wrote that while reading backlog, the way I see it F7 and F8 are a bit arbitrary, and whatever we do, we need to at least sync the keys with other devices that we support - droid4 has the same buttons: power and volume -/+, and we need to figure out how to handle them properly | 12:04 |
| Wizzup | F7/F8 feel arbitrary to me (why not F9/F10? etc), and xf86 volume keys might also not be ok | 12:04 |
| Wizzup | I suppose they are keys that serve different functions in different contexts | 12:06 |
| Wizzup | I am trying to think of equivalent stuff on PC keyboard layouts but don't quite know | 12:07 |
| parazyd | Well there's the Fn key in hardware, but I think that's not a valid thing on phones | 12:08 |
| parazyd | At the very least it's two keypresses and saving state | 12:09 |
| Wizzup | I don't mean it in that way per se | 12:09 |
| Wizzup | That's just about how a key is sent to the os, but I mean I am not sure what key would make (more) sense | 12:10 |
| Wizzup | brb | 12:10 |
| parazyd | ok | 12:10 |
| parazyd | I need to finish up the metapackages for stable now | 12:10 |
| parazyd | Could discuss more later | 12:10 |
| parazyd | Wizzup, uvos: We also have some libsdl1.2 in -devel. Should I promote it? | 12:11 |
| parazyd | note-to-self: Check why alpha/beta themes try to pull in devel theme | 12:12 |
| parazyd | uvos: Last 10 commits here (including changelog updates) https://github.com/maemo-leste/hildon-meta/commits/master | 12:18 |
| parazyd | uvos: Last commit here: https://github.com/maemo-leste/leste-config/commits/master | 12:18 |
| parazyd | This would go from devel to stable | 12:19 |
| parazyd | uvos: And then we need to introduce charge-mode, also via hildon-meta? | 12:20 |
| Wizzup | how many people have tested charge-mode? | 12:26 |
| Wizzup | I haven't yet | 12:26 |
| parazyd | I don't know | 12:27 |
| parazyd | It works here, on droid4/bionic you need to make boot.cfg init into softlevel=charge-mode | 12:28 |
| parazyd | And then if you boot with charger plugged you'll get the animation | 12:28 |
| parazyd | We should also have this on PP and N900 | 12:28 |
| parazyd | Ideally if the mainline u-boot on N900 supports boot.scr, then we're great | 12:28 |
| parazyd | Because then we can update cmdline this way | 12:29 |
| parazyd | Currently N900 cmdline is hardcoded in kernel | 12:29 |
| Wizzup | what do you mena, support boot.scr? | 12:29 |
| Wizzup | I am pretty sure we can have as many bootentries as we want in u-boot | 12:29 |
| Wizzup | it reads them from internal config and then from (e)mmc | 12:29 |
| parazyd | I mean passing cmdline from some file/variable | 12:29 |
| parazyd | Anything we can control is fine, doesn't have to be boot.scr | 12:30 |
| parazyd | Just giving an example | 12:30 |
| parazyd | https://github.com/maemo-leste/pine64-uboot/blob/master/boot.txt#L1 | 12:30 |
| parazyd | Like here | 12:30 |
| Wizzup | I am pretty sure we can do all of that, someone just needs to do it *and* make sure we can flash a certain u-boot version safely without messing wiht existing setups | 12:31 |
| parazyd | Yeah ok | 12:31 |
| sicelo | fremantle u-boit DOES support cmdline | 12:31 |
| parazyd | I already talked to Pali about this | 12:31 |
| Wizzup | sicelo: having both leste and fremantle generate u-boot menu using their own scripts is recipe for disaster though | 12:32 |
| parazyd | sicelo: Right, but thing is our n9xx-linux has hardcoded cmdline | 12:32 |
| parazyd | I'm not sure if it can be overriden | 12:32 |
| parazyd | https://github.com/maemo-leste/n9xx-linux/blob/maemo/beowulf/arch/arm/configs/n900_defconfig#L55 | 12:32 |
| Pali | u-boot loads bootmenu.scr from eMMC and it may boot menu entry may contain info to run e.g. boot.scr script from uSD | 12:33 |
| Pali | see: https://talk.maemo.org/showthread.php?t=81613 | 12:34 |
| parazyd | Yeah that's my point. We can then easily maintain Leste-specific boot.scr | 12:34 |
| Wizzup | yup | 12:35 |
| Pali | yes! | 12:35 |
| Pali | "run sdboot" tries to run boot.scr script from uSD | 12:36 |
| parazyd | Fantastic | 12:36 |
| Pali | and "run sdboot" is called by "External SD card" menu entry | 12:36 |
| Wizzup | parazyd: that is not the default btw | 12:37 |
| Pali | this menu entry is by default present if you do not have your own bootmenu.scr in eMMC | 12:37 |
| Wizzup | and it is only run upon user action | 12:37 |
| Wizzup | parazyd: does it also read from sd card? | 12:37 |
| Wizzup | err | 12:37 |
| Wizzup | Pali: ^ | 12:37 |
| Wizzup | when preparing the menu | 12:37 |
| Pali | uSD is not default boot option | 12:37 |
| Pali | default is attached kernel without cmdline | 12:38 |
| Pali | but bootmenu.scr in eMMC can specify custom default entry | 12:38 |
| parazyd | This still needs user interaction | 12:38 |
| parazyd | To change | 12:38 |
| Wizzup | Pali: the way I see it: (1) OS on eMMC and OS on uSD should both ideally be able to provide entries for the menu, and maybe even determine what should be default with some priority | 12:38 |
| Wizzup | and leste, I think, currently typically is on uSD and fremantle on emmc for most | 12:38 |
| Wizzup | so this way leste would have to override emmc on fremantle to get its values in, right? | 12:39 |
| parazyd | Wizzup: We would also use mainline u-boot and keep it up to date with apt | 12:39 |
| parazyd | Wizzup: This way we can also control the emmc script | 12:39 |
| Pali | well, you can overwrite u-boot source file include/configs/nokia_rx51.h to loads bootmenu.scr from uSD instead of eMMC | 12:39 |
| parazyd | Pali: Also, yes. | 12:39 |
| parazyd | We need our package anyway. | 12:40 |
| Pali | I think could go also into upstream u-boot | 12:40 |
| parazyd | Could it be a config option? | 12:40 |
| lel | parazyd labeled an issue: https://github.com/maemo-leste/bugtracker/issues/525 (Create n900-uboot package) | 12:41 |
| uvos | parazyd: parazyd: so charge mode should work everywhere, i tested it on d4, bionic and on the n900 by switching to the runlevel after boot | 12:41 |
| parazyd | I tested on d4/bionic only | 12:41 |
| parazyd | Updating my N900 now and will try too | 12:41 |
| uvos | ok someone should test it on pp | 12:41 |
| uvos | but thats what devel is for no? :P | 12:41 |
| parazyd | :) | 12:41 |
| uvos | parazyd: the only blemish being that currently /sys/class/power_supply/battery/status on mapphones just reflects current_now | 12:42 |
| Pali | is there any issue if u-boot always tries to load bootmenu.scr from uSD and if it fails then tries to load it from eMMC and if it fails then fallback to defalt? | 12:42 |
| uvos | so sometimes the device will fail to enter charge-mode becuase the device is using to mutch current at that moment | 12:42 |
| uvos | but thats just a mapphone kernel problem | 12:42 |
| parazyd | uvos: fail in what sense? | 12:42 |
| uvos | fail in the sense that it boots to hildon instead | 12:42 |
| parazyd | Pali: I suppose that's perfectly fine. | 12:42 |
| parazyd | uvos: ok | 12:42 |
| Pali | ok, so I can prepare patch for this | 12:43 |
| parazyd | 12:18 <parazyd> uvos: Last 10 commits here (including changelog updates) https://github.com/maemo-leste/hildon-meta/commits/master | 12:43 |
| parazyd | 12:18 <parazyd> uvos: Last commit here: https://github.com/maemo-leste/leste-config/commits/master | 12:43 |
| sicelo | Pali: +1 | 12:43 |
| parazyd | Have a look when you can please | 12:43 |
| uvos | parazyd: looks good. | 12:44 |
| uvos | (hildon-meta_ | 12:44 |
| uvos | ) | 12:44 |
| parazyd | ok, thanks | 12:44 |
| parazyd | This is still without charge-mode btw. | 12:44 |
| uvos | i would add chargeing-mode to the common metapackage btw (in devel only ofc) | 12:45 |
| parazyd | That goes into mapphone-kexecboot-config | 12:45 |
| uvos | yeah | 12:45 |
| parazyd | (runlevel) | 12:45 |
| uvos | right | 12:45 |
| parazyd | And yeah, dep into hildon-meta | 12:45 |
| parazyd | ok | 12:45 |
| uvos | for leste config its just this? https://github.com/maemo-leste/leste-config/commit/4f75983b5f475627fc201ad640c85bc692cf5a61? | 12:45 |
| parazyd | Yes, and seems there's no pending pulls | 12:46 |
| parazyd | So I guess that's it | 12:46 |
| uvos | ok yeah thats fine | 12:46 |
| parazyd | Unless there was something else you wanna add | 12:46 |
| parazyd | Alright | 12:46 |
| uvos | no | 12:46 |
| parazyd | Will build this in a little bit | 12:46 |
| uvos | for hildon meta it might make sense to only have fbkeybord in bionic | 12:47 |
| uvos | since you cant reach it elsewhere atm | 12:47 |
| uvos | but it dosent hurt to have it installed either | 12:47 |
| parazyd | ah but you asked me to add it to all of the non-keyboard devices :p | 12:47 |
| sicelo | Pali: I tried to boot Fremantle with upstream u-boot once (with kp image), but it didn't boot. Is this expected, or I made a mistake somewhere? | 12:47 |
| parazyd | imho it's fine if installed | 12:47 |
| uvos | right and you said we can figure out how to enter the runlevel later | 12:47 |
| uvos | im just saying its dead weight atm | 12:48 |
| uvos | but its fine | 12:48 |
| Pali | sicelo: it should work | 12:48 |
| sicelo | I'll try again and report back | 12:48 |
| Pali | if it does not work then something is broken and needs debugging... | 12:48 |
| freemangordon | Wizzup: kinda agree, but those new key should be really way more sane than F7/F8 to worth the effort of porting all the code to them. | 12:49 |
| sicelo | Okay. I'll test. The idea is to flash upstream u-boot (which Leste would prefer afaict), but still be able to boot Fremantle (what I prefer) | 12:49 |
| parazyd | dreamer, freemangordon, buZz, uvos, Wizzup, sicelo, etc.: Do you think it's a good idea to have another channel, say ##lestians (or propose another name), for non-dev Leste discussions? | 12:50 |
| uvos | parazyd: we did this before | 12:50 |
| uvos | parazyd: it dident work out mutch | 12:50 |
| parazyd | mhm | 12:51 |
| sicelo | I don't think it's good idea | 12:51 |
| parazyd | Asking because someone on Twitter asked. | 12:51 |
| Wizzup | freemangordon: yeah, I suppose so, I don't know how many handle the key, I guess web browser and some other apps. Something else to keep in mind is that some applications automatically handle zoom keys already, I think (I have to test), like pdf or image viewer, or browser, from debian, so keeping that kind of compat in mind when picking one might make sense (this likely won't be volume key ;-)) | 12:51 |
| parazyd | https://twitter.com/LiohMoeller/status/1405057382309376000 | 12:51 |
| freemangordon | parazyd: I agree here it is a bit noisy at times, but better keep it like it is | 12:51 |
| Wizzup | freemangordon: there is this: | 12:52 |
| Wizzup | #define XF86XK_ZoomIn0x1008FF8B /* zoom in view, map, etc. */ | 12:52 |
| Wizzup | #define XF86XK_ZoomOut0x1008FF8C /* zoom out view, map, etc. */ | 12:52 |
| uvos | i guess the comunication channel is the maemo forum | 12:52 |
| uvos | its almost dead but still | 12:52 |
| buZz | there's #maemo ? | 12:52 |
| buZz | does anyone really mind if lioh sits here to talk user things? | 12:53 |
| buZz | instead of dev | 12:53 |
| sicelo | you can simply respond that this channel is alright, and he can feel free to ask here | 12:53 |
| uvos | no | 12:53 |
| uvos | @buZz | 12:53 |
| freemangordon | Wizzup: sure there are slightly more sane keycodes, but does it worth? | 12:53 |
| Wizzup | buZz: nobody minds, but it might be hard to chat if there is much cross talk I imagine | 12:53 |
| parazyd | True there is #maemo | 12:53 |
| parazyd | I often forget | 12:53 |
| Wizzup | freemangordon: I think it probably is, if it means it will work out of the box with many other applicataions | 12:53 |
| sicelo | If people don't have time for him here, they most likely won't have time to look for him in another room | 12:53 |
| parazyd | sicelo: ++ | 12:53 |
| Wizzup | sicelo: uvos: iiuc it's mostly about cross talk | 12:53 |
| uvos | also https://talk.maemo.org/forumdisplay.php?f=66 | 12:53 |
| Wizzup | and maybe just a place in general to chat | 12:54 |
| sicelo | And lioh was asking about Leste issues (not fremantle issues) | 12:54 |
| uvos | i gues thats the real place for users | 12:54 |
| freemangordon | it still won't, as upstream kernel generates volume keys | 12:54 |
| uvos | ^^^ this is the real problem as changeing this involved changing everyones kernel | 12:54 |
| uvos | and you cant rely on udev remapping working | 12:55 |
| freemangordon | but the other option is to have broken UX | 12:55 |
| Wizzup | Why can't we rely on udev to remap a key for us? I think we already do that currently | 12:55 |
| bencoh | re. #lestians/whatever, I think #maemo should be the place for users at some point :) | 12:55 |
| * freemangordon is afk for a while | 12:55 | |
| uvos | Wizzup: that works for keybaords and other devices that generate scancodes | 12:55 |
| uvos | Wizzup: gipo keys and sutch do not generate scancodes | 12:55 |
| uvos | they genreate keycodes directly | 12:55 |
| uvos | you cant remap them | 12:55 |
| Wizzup | oh, MSC_SCAN ? | 12:55 |
| uvos | the kernel simply cant | 12:55 |
| uvos | yeah | 12:56 |
| uvos | volume keys are XF86Audio* its a fait accompli | 12:56 |
| uvos | leste has to deal with it | 12:56 |
| Wizzup | I am not at that point yet with my thought | 12:56 |
| Wizzup | We could simply change the dts in our kernels, for example, if it is beneficial | 12:57 |
| Wizzup | but before ew do that it would be nice to know if applications actually handle the xf86 zoom keys sensibly at all | 12:57 |
| uvos | Wizzup: sure but thats rather insane, do you want to change the kernel source for drivers that dont use dts? | 12:58 |
| uvos | like x86? | 12:58 |
| uvos | also then we cant fully share source with pmos etc | 12:58 |
| uvos | like on a x86 tablet you would have to change the ibm keyboard mapping with your hack to change the keycode... | 12:59 |
| uvos | or on vm etc | 12:59 |
| Wizzup | uvos: hm, you mean for the volume applet to work? | 12:59 |
| uvos | for the volume buttons to work | 12:59 |
| uvos | genreally | 12:59 |
| Wizzup | because they are not accessible physically? | 13:00 |
| uvos | hmm> | 13:00 |
| uvos | hmm? | 13:00 |
| sicelo | Is volume applet working/available yet? | 13:00 |
| uvos | no | 13:00 |
| Wizzup | sicelo: it requires PA setup | 13:00 |
| Wizzup | specific PA setup | 13:00 |
| * sicelo hasn't run Leste on N900 in many months now | 13:00 | |
| uvos | Wizzup: what do you mean accessible physically? | 13:00 |
| Wizzup | uvos: why would you need to remap? | 13:00 |
| uvos | ok so on any x86 device (lets say a tablet) the volume keys are the xf86 vol up and vol down | 13:01 |
| uvos | this is defined in kernel source | 13:01 |
| uvos | not dts | 13:01 |
| uvos | now what | 13:01 |
| uvos | how shal they work? | 13:01 |
| Wizzup | we could remap wit xkb I think, but yeah | 13:02 |
| Wizzup | we already specify specific keyboard layouts for our devices | 13:02 |
| uvos | no you cant | 13:02 |
| Wizzup | really? why not? | 13:02 |
| Wizzup | oh, it's a separate input device I guess.. | 13:02 |
| uvos | right | 13:02 |
| Wizzup | this is so silly | 13:02 |
| Wizzup | lol | 13:03 |
| uvos | really there is no way this can ever work right except accepting the fait accompli | 13:03 |
| uvos | and also accepting that all volume keys then behave the same | 13:03 |
| Wizzup | but firefox and such won't handle these keys | 13:04 |
| Wizzup | so we'd have to then fork firefox and other apps to make it handle them | 13:04 |
| uvos | that wont work with f7/f8 either | 13:04 |
| uvos | i mean there is no way to have everything magicly know what you mean if want vol to have mulitple meanings | 13:05 |
| uvos | if you want to have vol up down be the xf86 zoom keys | 13:05 |
| uvos | that you can do by mapping the xf86AudioVolume* to those in xcb | 13:05 |
| uvos | but the kernel keycode needs to stay xf86AudioVolume | 13:05 |
| uvos | or just change the config files of ff. | 13:06 |
| Wizzup | well, the xcb remap is what I was referring to earlier as well | 13:06 |
| Wizzup | did anyone look at the mobile config for firefox that some people mentioned btw? | 13:07 |
| uvos | right if you accept that xf86AudioVolume* are the vol keys in kernel and all vol keys will behave the same you can change the mapping xcb ofc. | 13:07 |
| Wizzup | https://gitlab.com/postmarketOS/mobile-config-firefox | 13:08 |
| uvos | i did, i think mine is better | 13:08 |
| Wizzup | which one is that? | 13:09 |
| uvos | just the private one on my device | 13:09 |
| uvos | id have to clean it a bit to release it | 13:09 |
| Wizzup | k | 13:09 |
| dreamer | parazyd: or a #leste-dev? :P | 13:14 |
| dreamer | (but I agree, this channel is good enough™ for now) | 13:14 |
| freemangordon | on fremantle the browser is not using volume keys for zoom | 13:14 |
| Pali | parazyd: uvos: here is patch https://pastebin.com/TZCtkeSA could you test it if it is fine for you? | 13:14 |
| freemangordon | Pali: do you want me to do anything else for u-boot? | 13:15 |
| Pali | I do not know if tom wants that your patch to be sent in git-format-patch | 13:16 |
| freemangordon | I bet he does | 13:16 |
| freemangordon | but as you know, I prefer to leave the paperwork to you :p | 13:17 |
| Pali | so for now just need to wait for tom answer | 13:21 |
| Wizzup | probably no reason to wait, can just send a rfc patch, right? | 13:22 |
| parazyd | Pali: mmc patch LGTM | 13:27 |
| parazyd | Pali: setenv mmctype ext4 | 13:27 |
| parazyd | Does this imply the partition has to be ext4? | 13:27 |
| Pali | ext4 means to read ext2/3/4 fs | 13:28 |
| parazyd | ok, and fat is fat | 13:28 |
| parazyd | ok | 13:28 |
| parazyd | Good | 13:28 |
| freemangordon | Pali: Wizzup: yes, no reason to wait, the answer we are waiting for is -mthumb related, not DM_USB | 13:28 |
| Pali | older u-boot version had separate ext2/3 and ext4 implementations, new u-boot has one unviersal ext2/3/4 implementation with just ext4load command, hence ext4 mmctype | 13:29 |
| Wizzup | ah, like mainline | 13:29 |
| Wizzup | parazyd: well keep in mind we'll have to be able to install u-boot first via leste, and we need to figure out ow to do it without breaking all the differnet setups | 13:30 |
| Wizzup | like, someone can have no u-boot on their device, and have fremantle kernel there, and boot leste via 0xFFFF | 13:30 |
| parazyd | Wizzup: Yeah as I said, already discussed this with Pali. There are helpful scripts. | 13:30 |
| Wizzup | in that case we do *not* want to flash u-boot | 13:30 |
| Wizzup | we'd break fremantle | 13:30 |
| Pali | you can extract current kernel from nand, append it into prepared u-boot binary and then flash this u-boot binary | 13:31 |
| Pali | (with appended kernel) | 13:31 |
| Wizzup | yeah, but can we decide to do that on our own? | 13:31 |
| parazyd | Wizzup: In any case, I'd prefer if we use mainline u-boot for Leste. | 13:31 |
| freemangordon | why not? | 13:31 |
| Wizzup | freemangordon: if you booted a livedistro, would you expect it to modify your grub config without asking you? | 13:32 |
| Pali | by default U-Boot boots attached (=fremantle) kernel | 13:32 |
| freemangordon | if there is a big fat warning | 13:32 |
| Wizzup | freemangordon: yes, that is what I am saying | 13:32 |
| freemangordon | ah, ok :) | 13:32 |
| Pali | and if you provide bootmenu.scr to eMMC you can overwrite default boot menu entry | 13:32 |
| Wizzup | I think the package should be avail in repos, but not in any meta, and we can juts have it be present on images we make, or something | 13:32 |
| Wizzup | well, no, that won't work still | 13:32 |
| Pali | and after above patch you can put bootmenu.scr also into uSD | 13:32 |
| parazyd | All promoted to stable | 13:47 |
| parazyd | Let me know if you experience issues upgrading | 13:47 |
| uvos | parazyd: btw with the charging-mode change you might want to conisder moving droid4-battery-calibration to sysint | 13:54 |
| parazyd | ah indeed | 13:55 |
| uvos | so there is a chance charging-mode ends up with a callibrated battery | 13:55 |
| parazyd | Made a note | 13:55 |
| parazyd | Doing N900 upgrade now | 13:55 |
| parazyd | Wizzup: * Caching service dependencies ... [ ok ] | 14:06 |
| parazyd | * Stopping ke-recv [ !! ] | 14:07 |
| parazyd | * Starting ke-recv presetup ... | 14:07 |
| parazyd | * Starting ke-recv ... | 14:07 |
| parazyd | This triggers a reboot | 14:07 |
| parazyd | https://parazyd.org/pub/dev/random/upgrade.txt | 14:07 |
| Wizzup | parazyd: shit, we pushed an update to users that causes another reboot like this? | 14:08 |
| uvos | abort abort :D | 14:08 |
| Wizzup | so can you reproduce it with just stopping ke-recv and starting it? | 14:08 |
| parazyd | Well, good incentive to solve it | 14:08 |
| parazyd | Wizzup: I can't | 14:08 |
| parazyd | This was apt | 14:08 |
| parazyd | As soon as I saw Stopping ke-recv Starting ke-recv presetup ... | 14:09 |
| parazyd | Screen went off, and LED went white like for shutdown | 14:09 |
| parazyd | Apt continued for a bit more | 14:09 |
| Wizzup | does /var/log/messages say anything? | 14:09 |
| Wizzup | it might just be part of something else | 14:09 |
| parazyd | Booting now | 14:09 |
| Wizzup | IIRC I debugged/narrowed it down already | 14:09 |
| Wizzup | but I don't remember. | 14:09 |
| parazyd | messages: http://sprunge.us/Fs1Mg4 | 14:10 |
| parazyd | syslog: http://sprunge.us/LrWEpG | 14:10 |
| parazyd | Jun 17 14:06:28 localhost DSME: new state: DSME_STATE_REBOOT | 14:11 |
| parazyd | Jun 17 14:06:28 localhost systemui-powerkeymenu[2932]: systemui: shutdown_ind from DSME, quitting | 14:11 |
| parazyd | Jun 17 14:06:27 localhost DSME: Process '/usr/sbin/ke-recv' with pid 2130 exited with return value 0 | 14:12 |
| parazyd | Jun 17 14:06:28 localhost DSME: Process '/usr/sbin/ke-recv' with pid 15501 exited with return value 1; spawning too fast -> reset | 14:12 |
| parazyd | Wizzup: See from Jun 17 14:06:28 in http://sprunge.us/LrWEpG | 14:12 |
| Wizzup | ok, I will dive into momentarily | 14:13 |
| parazyd | Thanks | 14:15 |
| parazyd | It's as if ke-recv doesn't restart properly and then dsme figures it should reboot | 14:17 |
| Wizzup | I think it looks like ke-recv doesn't start happily and it's set up in a way with dsme that failure to start it a few times makes it reset | 14:18 |
| parazyd | Rest of the upgrade went fine, fwiw | 14:18 |
| Wizzup | which makes sense, so we need to see why th restart fails | 14:18 |
| parazyd | Yes | 14:18 |
| parazyd | But I can't repro with /etc/init.d/ke-recv stop | 14:18 |
| Wizzup | try 'restart' | 14:18 |
| Wizzup | I will also try momentarily | 14:18 |
| Wizzup | busyatm | 14:18 |
| parazyd | Wizzup: Also works fine, no reboot | 14:19 |
| parazyd | pgrep -a ke-recv | 14:19 |
| parazyd | oops | 14:19 |
| parazyd | So pretty sure it's this in the ke-recv initscript | 14:24 |
| parazyd | /usr/sbin/dsmetool -U root -n -1 -t "/usr/sbin/ke-recv" | 14:24 |
| parazyd | -t --start-restart=<cmd> Start a process | 14:24 |
| parazyd | (on process exit, restart max N times then do SW reset) | 14:24 |
| parazyd | As to why it is unable to restart, I'm stumped | 14:25 |
| parazyd | I wonder if we're just trying too fast and we should let it settle some | 14:25 |
| Wizzup | I don't think it should fail 10 times in a row though | 14:26 |
| Wizzup | (still busy) | 14:26 |
| parazyd | Right | 14:26 |
| parazyd | np | 14:26 |
| meldrian | Guess the easiest way is asking here, is there a client for fediverse services on maemo leste? | 16:55 |
| meldrian | Like gnuscoial, mastodon, friendica, etc. | 16:56 |
| parazyd | If there's something on Debian - yes. :) | 16:58 |
| parazyd | We don't have a native app. | 16:58 |
| Wizzup | (yet) | 17:02 |
| meldrian | Wait so, for example, tootle might work? (https://packages.debian.org/de/sid/tootle) | 17:02 |
| Wizzup | try 'apt get install tootle' :) | 17:02 |
| Wizzup | well, is it only in sid? | 17:02 |
| freemangordon | apt-get install will show :) | 17:03 |
| freemangordon | "E: Unable to locate package tootle" | 17:04 |
| freemangordon | Wizzup: it is in bullseye too | 17:04 |
| meldrian | Once the new battery is delivered i'll try to ressurect the n900 for home use with meamo leste. Just want to check if fediverse is one of its borders. Iam reliefed its not. | 17:05 |
| freemangordon | actually this particular client is not available in leste | 17:06 |
| freemangordon | because it is based on current debian stable | 17:06 |
| freemangordon | but maybe it will just compile, who knows | 17:07 |
| meldrian | It doesn't need to be tootle. Every client with basic functionality will do it. | 17:08 |
| bencoh | considering the deps, it might compile easily | 17:08 |
| Wizzup | it might even just dpkg -i | 17:08 |
| freemangordon | meldrian: whatever is available in debian stable, is available in leste as well | 17:08 |
| bencoh | Wizzup: doesn't sound great ABI-wise, but dpkg-buildpackage should be fine | 17:09 |
| freemangordon | :nod: | 17:09 |
| meldrian | ... and that's a lot. Can't wait to begin testing. | 17:09 |
| freemangordon | Pali: yay, seems WDT patch has been merged into -next :) | 21:04 |
| freemangordon | https://github.com/u-boot/u-boot/commit/e61a4ff13f36a9952b4ecdfaa209963d411d2884 | 21:07 |
| freemangordon | Pali: now we only need that DM_USB patch series | 21:08 |
| sicelo | <3 | 21:42 |
| Pali | freemangordon: perfect! | 23:53 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!