| mighty17[m] | Yes it looks like pvr-omap4 fails for sure | 08:52 |
|---|---|---|
| * mighty17[m] uploaded an image: (187KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/DKWUvKlVWZHcXPwykhKrqxsx/Screenshot_20210614-121334_Pixel_Launcher.png > | 08:53 | |
| uvos | it sais that it cant open the drm node so either the pvr module dident load or it dident probe | 09:20 |
| uvos | again the missing moudle line at the top of that screenshot suggests you are missing modules somehow | 09:21 |
| parazyd | uvos: Added you to repos | 09:23 |
| uvos | parazyd: great thanks | 09:25 |
| parazyd | You're welcome | 09:25 |
| parazyd | Also you should be able to build them from the other CI channel | 09:25 |
| parazyd | (I set that up beforehand) | 09:26 |
| lel | parazyd closed a pull request: https://github.com/maemo-leste/leste-config/pull/23 (Mapphones: switch away from mono mode on exiting internal speaker hifi output) | 09:28 |
| freemangordon | hi Pali | 09:28 |
| Pali | hi! | 09:28 |
| freemangordon | any hint where shall I start from in regards to uboot/usb? | 09:29 |
| freemangordon | I guess I shall pull latest master first, no? | 09:31 |
| parazyd | btw. on friday I'll do a talk about Leste on Bitreichcon gopher://bitreich.org/1/con/2021 gopher://bitreich.org/0/usr/20h/phlog/2021-06-13T16-57-32-547583.md | 09:43 |
| parazyd | 2000 CET | 09:43 |
| Pali | freemangordon: yes, pull latest master and build u-boot via 'make' | 09:46 |
| Pali | it prints deprecated warning about rx51 and USB | 09:46 |
| Pali | and this needs to be resolved | 09:46 |
| Pali | make nokia_rx51_config && make CROSS_COMPILE=arm-linux-gnueabi- | 09:47 |
| parazyd | uvos: So regarding fbkeyboard, do you want it for devices like D4 and N900 too? | 09:50 |
| mighty17[m] | uvos is omap_drm supposed to be a module, I have it =y | 09:57 |
| mighty17[m] | Omap2plus defconfig didn't boot for me (don't know why no log just black screen) | 09:57 |
| mighty17[m] | So back to using my config (for now) | 09:59 |
| uvos | parazyd: no | 10:04 |
| uvos | parazyd: just no kbd deivces, but we need a way to boot to fbkyboard shell thats not dependant on the bootloader offering some kind mulitboot feature | 10:05 |
| uvos | mighty17[m]: jeah no shit it dosent work then | 10:05 |
| uvos | mighty17[m]: your not building the pvr module | 10:06 |
| mighty17[m] | uvos: it works in pmOS xD | 10:38 |
| freemangordon | Pali: thanks | 11:26 |
| mighty17[m] | @uvos: using drm as module, display doesnt seem to be working | 11:26 |
| Pali | freemangordon: warning message says that it is needed to migrate to DM USB... but I'm not sure if this is the right way as DM USB is for host mode (connecting USB disk to n900), but U-Boot uses USB only for periperal mode (exporting USB TTY to computer) | 11:27 |
| Pali | and it seems that neither musb peripheral drivers nor usbtty driver use DM USB | 11:28 |
| freemangordon | Pali: ok, will see | 11:28 |
| Pali | and I'm not sure what to do with it | 11:28 |
| Pali | plus DM USB depends on migration to device tree which n900 uboot does not use (device tree increase uboot size upper limit and does not have any advantages; so currently it is not used) | 11:29 |
| freemangordon | Pali: what benefits we have if n900 is kept upstream? | 11:30 |
| Pali | bug fixes, new features etc... | 11:31 |
| Pali | now we should be able to boot directly zImage kernels | 11:31 |
| Pali | without converting it to uImage | 11:31 |
| freemangordon | I see | 11:32 |
| Pali | fixed nand access, etc... | 11:33 |
| freemangordon | Pali: BTW, "[PATCH] nokia_rx51: Make onenand working" is merged, right? | 11:34 |
| Pali | yes, it should be! | 11:34 |
| freemangordon | ok | 11:34 |
| freemangordon | Pali: what about CONFIG_WDT? | 11:37 |
| Pali | for CONFIG_WDT I have sent patch months ago | 11:43 |
| Pali | it is waiting for review | 11:43 |
| Pali | http://patchwork.ozlabs.org/project/uboot/list/ | 11:44 |
| Pali | http://patchwork.ozlabs.org/project/uboot/patch/20210309201915.16586-1-pali@kernel.org/ | 11:44 |
| freemangordon | Pali: hmm, it seems we shall enable CONFIG_USB_MUSB_GADGET and some serial gadget | 11:46 |
| freemangordon | n900 appears as a serial device now, right? | 11:47 |
| Pali | yes it appears as usbtty | 11:47 |
| Pali | USB CDC ACM | 11:47 |
| freemangordon | there should be serial gadget IIUC | 11:47 |
| freemangordon | Pali: seems we shall port f_acm from linux | 11:56 |
| Pali | why? there is already usbtty code working | 11:56 |
| freemangordon | as a gadget? | 11:56 |
| Pali | not as gadget but as a driver | 11:56 |
| Pali | which is already in use | 11:57 |
| Pali | I have fixed bugs in it half year ago | 11:57 |
| freemangordon | ok, lemme see what is going to happem | 11:57 |
| freemangordon | *happen | 11:57 |
| Pali | (I do not see reason/benefit for backporting additional driver if there is already one which is working and which was debugged to work properly) | 11:58 |
| freemangordon | ok | 11:59 |
| freemangordon | lemme try to enable that DM_USB first | 11:59 |
| Pali | new driver = new issues = new debugging | 11:59 |
| freemangordon | sure | 11:59 |
| Pali | I guess enabling DM_USB would not work because n900 does not use CONFIG_OF | 11:59 |
| Pali | and also I do not see any benefit for rewriting n900 code to CONFIG_OF - it does not bring any functionality, only bugs | 12:00 |
| freemangordon | but it will be dropped otherwise :) | 12:04 |
| freemangordon | also, how does i2c_dm works then? | 12:05 |
| freemangordon | didn't you send patches about that? | 12:05 |
| freemangordon | I don;t see them upstream | 12:05 |
| freemangordon | oh, wait | 12:06 |
| freemangordon | it is there | 12:06 |
| Pali | DM I2C is there | 12:08 |
| Pali | DM I2C works with and also without CONFIG_OF | 12:09 |
| Pali | we are using variant without CONFIG_OF and data for i2c are stored in C struct | 12:09 |
| Pali | at the end of the file board/nokia/rx51/rx51.c | 12:09 |
| Pali | but DM USB somehow does not to load data from support C struct ... and therefore depends on CONFIG_OF | 12:10 |
| freemangordon | ok, will look into it | 12:27 |
| * enyc meows | 12:56 | |
| enyc | good to see channels all nicely active on libera now for all sorts, and interestingly [m] matrix connections here | 12:56 |
| enyc | but not main #matrix channles etc last I checked ;/ | 12:56 |
| freemangordon | Pali: so, you want migration to DT avoided? | 15:39 |
| Pali | DT is big, we do not have size for its support | 15:39 |
| freemangordon | but, we can;t have DM_USB without OF, IIUC | 15:40 |
| freemangordon | OF == DT, right? | 15:40 |
| freemangordon | DM_USB requires CONFIG_OF_CONTROL | 15:41 |
| freemangordon | ok, DT increases binary size by ~100k | 15:47 |
| freemangordon | and we have 256k, right? | 15:47 |
| freemangordon | Pali: ^^^ | 15:47 |
| Pali | looks like that, but question is why DM USB needs OF control | 15:48 |
| Pali | OF = DT | 15:48 |
| Pali | or rather, why we need it for just usbtty? | 15:48 |
| freemangordon | going to check | 15:48 |
| Pali | DT needs new code plus whole DTS binary | 15:48 |
| Pali | there is really no space for it | 15:48 |
| freemangordon | yeah | 15:49 |
| Pali | it is just wasting of space | 15:49 |
| freemangordon | https://pastebin.com/SMCn4zqp | 15:51 |
| freemangordon | Pali: did you hear from the maintainers after your last mail? | 15:56 |
| Pali | no | 15:57 |
| Pali | for other drivers there is DTS to Cstruct conversion function, so drivers works with DTS or without DTS | 15:57 |
| Pali | therefore devices can be initialized automatically from DTS | 15:58 |
| Pali | or manually by specifying them in board c file (like for rx51 i2c) | 15:58 |
| freemangordon | not usb it seems | 15:58 |
| freemangordon | maybe we shall patch it | 15:58 |
| freemangordon | but, if you look in the Makefile, it explicitly requires CONFIG_OF_CONTROL for USB | 16:01 |
| freemangordon | Pali: do you define board_fdt_blob_setup() somewhere? | 16:03 |
| Pali | it defines probably because there is no conversion function... like for i2c | 16:03 |
| Pali | board_fdt_blob_setup is not defined, we do not have FDT = DT blob | 16:04 |
| freemangordon | so, we shall implement one, no? | 16:04 |
| freemangordon | (conversion function) | 16:04 |
| Pali | maybe? | 16:04 |
| Pali | but I still do not know if DM USB should / can be used for rx51 usbtty | 16:05 |
| freemangordon | where it is defined for i2c? | 16:05 |
| freemangordon | understandable, but what are the options? | 16:05 |
| Pali | omap_i2c_of_to_plat() | 16:05 |
| Pali | maybe other option is look how to use usbtty code without that "deprecated" warning | 16:06 |
| freemangordon | hmm, this looks like i2c is not converted to DT | 16:06 |
| freemangordon | that's why they use conversion function | 16:06 |
| Pali | omap_i2c_of_to_plat() is used for converting DTS to plat code | 16:06 |
| Pali | in rx51 we use plat code directly | 16:06 |
| freemangordon | exactly | 16:07 |
| freemangordon | i2c driver itself does not use DT, but plat struct | 16:07 |
| freemangordon | that | 16:07 |
| freemangordon | 's | 16:07 |
| freemangordon | why the conversion | 16:07 |
| freemangordon | while DM_USB ises DT directly | 16:07 |
| Pali | and maybe it should use C structs too? | 16:07 |
| freemangordon | not sure | 16:08 |
| freemangordon | maybe | 16:08 |
| freemangordon | Pali: hmm, actually it seems the only places CONFIG_DM_USB is usb.c itself and 2 board files | 16:17 |
| freemangordon | so this is the same code, just trying to get its data from DT | 16:17 |
| freemangordon | BTW, any clue why DT support code is so big? 100k for parsing some binary blob seems like an overkill to me | 16:20 |
| Pali | because they are using standard fdt library for it, which is big | 16:24 |
| Pali | and also fdt blob itself is big for omap3/n900 (look into kernel) | 16:24 |
| freemangordon | hmm, OF_PLATDATA seems to be available, but for SPL/TPL only | 16:24 |
| freemangordon | hmm, they say DT overhead is 3k | 16:27 |
| Pali | this is also too big | 16:27 |
| freemangordon | ok, why don;t you ask the maintainers what to do there, as it is obviously that we have some size constrains | 16:30 |
| Pali | I have already wrote to ML... I'm not getting any responces to my patches and my emails | 16:31 |
| Pali | it look half of year once somebody respond | 16:31 |
| freemangordon | maybe ping thm | 16:31 |
| freemangordon | *them | 16:31 |
| freemangordon | I'll reply to your latest mail with my findings, lets see | 16:32 |
| Pali | I was sending periodic pings last year... | 16:32 |
| Pali | ok, try to write reply, maybe you will get responce more quickly | 16:36 |
| freemangordon | mhm | 16:36 |
| freemangordon | Pali: sorry, can;t recall, where this 256k limit comes from? | 16:40 |
| Pali | kernel starts at 256k offset | 16:41 |
| Wizzup | so this is for supporting attached kernel? | 16:41 |
| freemangordon | Pali: I guess we shall give up on that (attached kernel) | 16:43 |
| Pali | and does it makes sense to include tons of useless glue code? | 16:44 |
| freemangordon | no, for sure | 16:44 |
| freemangordon | ok, lemme write that mail and see | 16:44 |
| Pali | this looks like somebody really wants to remove n900 code from uboot... | 16:45 |
| Pali | ...patches are waiting on ML without review/comments for half of year... | 16:45 |
| freemangordon | could be, seems FOSS is not what it used to be, see Xorg | 16:46 |
| Pali | ... and a patch for removal n900 was sent prior reviewing/commenting pending patches... | 16:46 |
| freemangordon | Pali: any clue why it needs 100k for DT parsers? again, they say it should be 3k | 17:02 |
| Pali | I do not know | 17:02 |
| Pali | I know that DT parser and big DT blobs are also problem for boards with SPL builds | 17:03 |
| Pali | where space for SPL is also limited | 17:03 |
| Pali | due to this reason Marek worked on LTO support in U-Boot, to reduce final u-boot mage binary size | 17:03 |
| freemangordon | please have a look at of-plat.rst | 17:04 |
| freemangordon | oh, this linked | 17:04 |
| freemangordon | 247312 | 17:05 |
| Pali | "approximately 3KB on Thumb 2" | 17:05 |
| freemangordon | yes | 17:05 |
| Pali | but we do not use thumb2 | 17:05 |
| freemangordon | so, 5k | 17:05 |
| Pali | so it is even bigger | 17:05 |
| freemangordon | ok, but not 100k | 17:05 |
| freemangordon | and I think we shall be able to shave 5k | 17:05 |
| freemangordon | if it comes to it | 17:06 |
| Pali | well, enabling DTS means to convert whole n900 code to DTS | 17:06 |
| Pali | which is tons of work | 17:06 |
| freemangordon | no, we can use OF_PLATDATA | 17:07 |
| Pali | plus, there would be issues like how to disable code which should not be touched by u-boot (as whole hw initialziation is done by nolo) | 17:07 |
| freemangordon | look at usb.c, DM_USB just changes the way it gets HW data from | 17:08 |
| freemangordon | nothing more | 17:08 |
| freemangordon | no code is being added/removed | 17:08 |
| Pali | but it looks like that ./common/usb.c contains code for USB host mode | 17:09 |
| Pali | all these we do not need | 17:09 |
| Pali | we do not use it in u-boot | 17:09 |
| freemangordon | so you say that usb.c is not compiled if DM_USB is not defined? | 17:10 |
| Pali | it is | 17:10 |
| freemangordon | so, what is the difference then? | 17:10 |
| Pali | I'm saying that most of that code is not used | 17:10 |
| freemangordon | host mode code is there with and without DM_USEB | 17:10 |
| freemangordon | sure | 17:10 |
| freemangordon | so? adding DM_USB_ROLE? | 17:11 |
| uvos | Wizzup: im here if you are ready wrt mce | 17:12 |
| freemangordon | to not build hostmode code? | 17:12 |
| Pali | so looks like we just need something like U_BOOT_DRVINFO() for usb periphal mode | 17:12 |
| freemangordon | yes | 17:12 |
| uvos | Pali: forced move to OF is painfull for sure, but it seams to have done the kernel a lot of favors, so i can understand why uboot would like to follow | 17:12 |
| freemangordon | but it seems this works only if SPL is enabled | 17:13 |
| freemangordon | Pali: I see "select OF_LIBFDT if !OF_PLATDATA" | 17:13 |
| Pali | uvos: but u-boot is not operating system, for most boards it is just small bootloader | 17:13 |
| uvos | it still has to deal with the same shit as the kernel to initalize the hw | 17:14 |
| uvos | so it has the same problems as are solved by of in kernel | 17:14 |
| Pali | SPL binary is just for loading u-boot | 17:14 |
| Pali | uvos: yes, but n900 is somehow special as most of hw init is done by nolo... and we need this stuff to not be touched by u-boot | 17:14 |
| uvos | sure on n900 that may be true | 17:14 |
| freemangordon | Pali: yes, the point is that u-boot on n900 is not SPL | 17:15 |
| Pali | due to this stiff there were issues with emmc, i2c, onenand and freezes | 17:15 |
| freemangordon | hmm, wait, how U_BOOT_DRVINFOS() work in n900 board file? | 17:18 |
| freemangordon | Pali: ^^^? | 17:19 |
| freemangordon | according to doc it should not | 17:19 |
| Pali | no idea... it works fine | 17:20 |
| Pali | I just used same construction which was used in other board files | 17:21 |
| freemangordon | yes, I see, but... | 17:21 |
| freemangordon | Pali: I would say it does not | 17:25 |
| freemangordon | (work) | 17:25 |
| freemangordon | most probably because i2c is setup by nolo it works fine | 17:25 |
| Pali | both i2c, mmc and wtd is working fine! | 17:25 |
| Pali | I have tested it | 17:25 |
| Pali | and checked that relevant code is called | 17:25 |
| Pali | I did it about half year ago (maybe more) | 17:26 |
| Pali | so it is possible if something was changed, then it does not work now | 17:26 |
| Pali | but at that time it for sure worked | 17:26 |
| freemangordon | look at i2c-uclass, it has #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA) all over the place | 17:27 |
| freemangordon | like https://github.com/trini/u-boot/blob/master/drivers/i2c/i2c-uclass.c#L664 | 17:28 |
| freemangordon | so, are you sure dm_i2c_set_bus_speed() gets called? | 17:28 |
| freemangordon | I don't see how is that possible | 17:28 |
| Pali | this is called from https://github.com/trini/u-boot/blob/master/drivers/i2c/omap24xx_i2c.c via __omap24_i2c_setspeed | 17:30 |
| Pali | and __omap24_i2c_setspeed is called during probing i2c driver | 17:31 |
| freemangordon | Pali: the point is that I think U_BOOT_DRVINFOS() in rx51_c are simply not compiled or ignored. Unless I don;t understand how is that supposed to work | 17:33 |
| Pali | they are not ignored for sure | 17:34 |
| Pali | otherwise my watchdog patch would not work | 17:34 |
| Pali | but I have tested that it correcly initalize and is reset function periodically called | 17:34 |
| freemangordon | hmm | 17:35 |
| Pali | so U_BOOT_DRVINFOS() in rx51.c must be compiled and loaded | 17:35 |
| freemangordon | ok, seems I need more time to think about that | 17:35 |
| Pali | U_BOOT_DRVINFO expands to ll_entry_declare which expands to __section(".u_boot_list_2_"#_list"_2_"#_name) | 17:37 |
| freemangordon | mhm | 17:37 |
| Pali | so something which is used by linked script | 17:37 |
| Pali | *linker | 17:37 |
| freemangordon | but, who uses that? | 17:37 |
| freemangordon | see https://github.com/trini/u-boot/blob/master/drivers/mmc/mxsmmc.c#L578 | 17:37 |
| freemangordon | I don;t see any similar code in omap_hsmmc for example | 17:38 |
| uvos | Wizzup: will be back in a bit (if you arrive in the mean time) | 17:38 |
| Pali | freemangordon: I guess this is feature of DM to automatically initialize drivers from these plat structs | 17:39 |
| Pali | omap hs mmc has: .plat_auto= sizeof(struct omap_hsmmc_plat), | 17:39 |
| freemangordon | mhm | 17:40 |
| freemangordon | seems AM335X board code has something similar to what we need | 17:43 |
| freemangordon | Pali: how to check in Makefile is some config option is n? | 17:50 |
| Pali | ifeq ($(CONFIG_XYZ),y) | 17:51 |
| freemangordon | thanks | 17:51 |
| Pali | and then on next line endif | 17:51 |
| freemangordon | yeah | 17:51 |
| Wizzup | uvos: can we aim for say 1930? | 17:53 |
| lioh_ | hi all. I am trying to follow the instructions on the wiki for my N900 but I always get this message: https://termbin.com/73ar | 18:23 |
| lioh_ | do you have any idea what i am doing wrong? | 18:23 |
| freemangordon | you should be holding F while powering-on the device | 18:29 |
| freemangordon | sorry, 'U', not 'F' | 18:29 |
| freemangordon | lioh_: ^^^ | 18:33 |
| lioh_ | Thanks, worked now. | 18:37 |
| lioh_ | Is there a way to increase the brightness in the tty? | 18:37 |
| mighty17[m] | @uvos ping, more updates tried mmc fix by tmlin.d doesnt seem to work, same rootfs issue, next is it necessary to build CONFIG_DRM and CONFIG_DRM_OMAP as modules as with that there is no display (maybe coz of mmc randomness) | 18:41 |
| mighty17[m] | can i flash maemo to emmc? would make things easier :P | 18:44 |
| lioh_ | I have flashed it using the following command sudo ./0xFFFF -m test/u-boot-2013.04-2.bin -f and on boot i still have to always type run sdboot. Is there a way to automate that? | 18:44 |
| Wizzup | uvos: hi | 19:48 |
| uvos | hi | 19:48 |
| uvos | parazyd: https://maedevu.maemo.org/irc-this-week.txt is sortof broken | 19:48 |
| Wizzup | uvos: I can be avail in a bit | 19:48 |
| uvos | Wizzup: ok me to | 19:48 |
| uvos | \me i think these kinds of statemens break it by creating invalid chars | 19:49 |
| Wizzup | uvos: finishing dinner here at a friend, 2030 ok, or too late? can also do earlier | 19:49 |
| * uvos or rather these | 19:49 | |
| uvos | this causes browsers to treat it as data instead of text | 19:49 |
| uvos | parazyd: maybe sanitize your input | 19:50 |
| uvos | Wizzup: that should be fine | 19:50 |
| uvos | parazyd: i also lack authority to build charge-mode please kick it and also give me rights. | 19:51 |
| uvos | mighty17[m]: this and omap2plus_defconfig not booting suggests you have not installed the modules properly as has been mentioned manny times allready | 19:51 |
| uvos | the modules should be in /lib/modules/$(uname -r) | 19:52 |
| parazyd | uvos: You can build it from IRC | 19:52 |
| uvos | parazyd: no i cant | 19:52 |
| parazyd | I haven't seen you try | 19:53 |
| uvos | it saies not authorized | 19:53 |
| mighty17[m] | uvos: it is in there (there used to be 5.10.x from the original img of d4 i placed 5.11.0 (exactly the uname -r) of the kernel there) | 19:53 |
| mighty17[m] | im still sus about the mmc randomness breaking and thus modules dont load or smth, can i flash in emmc? | 19:54 |
| uvos | sure you can flash it anywhere you want | 19:54 |
| uvos | as long as you change cmdline apropriately | 19:54 |
| mighty17[m] | how do i flash in emmc | 19:55 |
| uvos | mighty17[m]: fastboot | 19:56 |
| uvos | you can just flash the image of just the rootfs (not with boot and the mbr) via fastboot | 19:56 |
| uvos | to whereever | 19:56 |
| mighty17[m] | uvos Samsung has no fastboot | 20:01 |
| mighty17[m] | It's own Download mode | 20:01 |
| uvos | then i have no idea | 20:01 |
| uvos | right samsung uses its own propriatary bootloader setup instead of basing something of the common andorid bootloader system | 20:02 |
| mighty17[m] | What would be the fastboot cmd? | 20:02 |
| mighty17[m] | Or rather with twrp? | 20:03 |
| uvos | fastboot flash whatever image | 20:03 |
| uvos | no | 20:03 |
| uvos | whatever being a partition | 20:03 |
| uvos | twrp is mainly a piece of crap best avoided :P | 20:05 |
| mighty17[m] | Ugh I can try heimdall ig | 20:10 |
| mighty17[m] | Will try putting it in system partition | 20:10 |
| mighty17[m] | I don't think 2gb will fit there tho, don't wanna wipe my userdata | 20:10 |
| mighty17[m] | dont think heimdall supports .img :( well im stuck | 20:13 |
| uvos | Wizzup: hi | 21:14 |
| Wizzup | hi! | 21:15 |
| Wizzup | let's chat mce | 21:16 |
| uvos | sure | 21:17 |
| Wizzup | should we go over the PRs one by one? | 21:17 |
| uvos | sounds sane | 21:17 |
| Wizzup | ok | 21:17 |
| uvos | ok starting with #32. this one simply makes devlock and tklock a lodable module and contains no functional changes] | 21:18 |
| uvos | actually thats not true | 21:19 |
| uvos | it also removes the kp event disable | 21:19 |
| uvos | this was a feature | 21:19 |
| uvos | where mce disabled the evdev devices using a kernel interface that was added to the n900 kernel by nokia | 21:20 |
| Wizzup | right, the /disable part | 21:20 |
| uvos | right | 21:21 |
| Wizzup | merging it locally now | 21:21 |
| Wizzup | sce | 21:21 |
| Wizzup | sec* | 21:21 |
| uvos | also i removed the usb_cable_trigger, this removes the device unlocking of the device on usb plug | 21:22 |
| uvos | this is a temporary thing only | 21:22 |
| uvos | i later added this to a common/different module | 21:22 |
| uvos | but that was after cmake | 21:22 |
| uvos | so for now merging the prs would make this not work | 21:22 |
| uvos | (note pluging in usb will still wake the device just not unlock it) | 21:22 |
| Wizzup | ok | 21:22 |
| Wizzup | ok, that merged | 21:24 |
| Wizzup | uvos: what's next? | 21:25 |
| uvos | i thought we where going in order | 21:25 |
| uvos | ok so the next one is #34 | 21:26 |
| uvos | this makes dsme support a module | 21:26 |
| uvos | and contains no functional changes. the only major thing here is taht the request_*() functions | 21:26 |
| Wizzup | uvos: what's next => what is next in order, what number is what I meant | 21:26 |
| uvos | where turned into a data pipe system_power_request_pipe | 21:27 |
| uvos | this touches a lot of code | 21:27 |
| uvos | but its mostly a trival change | 21:27 |
| uvos | this is so that we can later have a more coherent plugin interface | 21:27 |
| Wizzup | righr | 21:27 |
| Wizzup | makes sense | 21:27 |
| Wizzup | let me review it briefly | 21:27 |
| uvos | also the --debug-mode flag of mce is gone | 21:28 |
| Wizzup | hm, it doesn't rebase cleanly on master | 21:28 |
| uvos | this simply disabled dsme support before | 21:28 |
| Wizzup | (makefile changes) | 21:28 |
| uvos | the same thing is now accived by not loading the module | 21:28 |
| uvos | Wizzup: ok | 21:28 |
| Wizzup | should be trivial | 21:28 |
| uvos | shal i rebase you will you? | 21:28 |
| Wizzup | maybe you can, if you have a moment | 21:29 |
| uvos | sure | 21:29 |
| Wizzup | the conflict is in the Makefile | 21:29 |
| Wizzup | between master and git://github.com/IMbackK/mce.git dsme-module | 21:29 |
| uvos | Wizzup: sure sec | 21:30 |
| Langoor | Hey all! I'm having some issues with the pre-built images on the N900.. Flashed it to a microSD and it seems to boot fine, but the desktop enviroment seems to be broken. | 21:37 |
| Langoor | I get a lockscreen but only on the left-half of the LCD, when swiping to unlock the screen goes black | 21:37 |
| Wizzup | Langoor: hmm... latest image? | 21:39 |
| Langoor | Yeah, also tried one before that | 21:39 |
| Langoor | https://i.imgur.com/GZOPa9P.jpg | 21:39 |
| Langoor | That's what i'm looking at | 21:40 |
| Wizzup | sounds hildon-desktop is borked | 21:40 |
| Langoor | I'll try the oldest one that's on the download page as well.. just to be sure | 21:41 |
| Wizzup | uvos: did you manage? | 21:44 |
| uvos | im on it | 21:44 |
| Wizzup | ok | 21:45 |
| Langoor | Samei ssue with that build as well | 21:47 |
| uvos | its a bit messy | 21:48 |
| uvos | ok its building now | 21:48 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/mce/pull/34 (Dsme module) | 21:50 |
| uvos | should be fine | 21:50 |
| uvos | now | 21:50 |
| Wizzup | yes | 21:51 |
| Wizzup | ok, that's in master | 21:51 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/mce/pull/34 (Dsme module) | 21:51 |
| uvos | wiat | 21:52 |
| uvos | you dident close #32 | 21:52 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/mce/pull/32 (Modular lock) | 21:52 |
| uvos | ok | 21:52 |
| uvos | ok #35 conflicts also now in makefile and mce.ini | 21:52 |
| uvos | :P | 21:52 |
| uvos | so this one is a stand alone module | 21:53 |
| uvos | that you can load instead of tklock | 21:53 |
| uvos | and it just lets you use xdg-lock or no lockscreen | 21:53 |
| uvos | let me rebase | 21:53 |
| Wizzup | ok | 21:55 |
| Wizzup | ty | 21:55 |
| uvos | ok | 21:58 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/mce/pull/35 (Adds Lock generic module) | 21:58 |
| Wizzup | checking | 22:00 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/mce/pull/35 (Adds Lock generic module) | 22:01 |
| uvos | ok we can skip #41 | 22:02 |
| uvos | and reserve it for some day | 22:02 |
| uvos | when we rm dsme | 22:02 |
| Wizzup | s/when/if/ ;) | 22:02 |
| Wizzup | but yes | 22:02 |
| uvos | eh | 22:02 |
| uvos | ok so #43 is self evident i think | 22:03 |
| parazyd | Langoor: I'll check what's up tomorrow | 22:03 |
| parazyd | To see if it happens on my device too | 22:03 |
| Wizzup | https://github.com/maemo-leste/mce/pull/43/files#diff-ed5f28af663384bdbc28ef834511cb881c6bd66c8e202a9e7f46a1eb80968445R27 should this be || or && | 22:03 |
| uvos | || we shutdown if there is no call | 22:05 |
| uvos | or if the call is not an emergency | 22:05 |
| Wizzup | ok | 22:05 |
| Wizzup | uvos: what adds libdisplay? that is in another pr I guess? | 22:05 |
| uvos | Wizzup: libdisplay? | 22:05 |
| Wizzup | #43 has that in it's diff but I don't think it needs it | 22:05 |
| Wizzup | e.g. | 22:05 |
| Wizzup | <<<<<<< HEAD $(MODULE_DIR)/libbattery-guard.so \ $(MODULE_DIR)/libdisplay.so \ | 22:05 |
| Wizzup | ======= | 22:05 |
| Wizzup | (newlines removed :() | 22:05 |
| uvos | Wizzup: we should have libdsiplay and it should be built | 22:06 |
| uvos | Wizzup: display-dev dissapeard | 22:06 |
| Wizzup | what merged it in then? | 22:06 |
| uvos | Wizzup: it was allways there in freemantle even | 22:06 |
| Wizzup | ok, let me re-check the conflict... | 22:06 |
| uvos | but we had display-dev and later mv display-dev to display | 22:06 |
| Wizzup | hm, I think PR 43 is just really old | 22:07 |
| Wizzup | Auto-merging Makefile | 22:07 |
| Wizzup | CONFLICT (content): Merge conflict in Makefile | 22:07 |
| Wizzup | error: could not apply 350457d... display: remove superceed by soon to be renamed display-dev | 22:07 |
| uvos | yeah | 22:07 |
| uvos | ok | 22:07 |
| uvos | so i removed it for one commit | 22:07 |
| uvos | the end result needs to be that display is built but display-dev is not | 22:07 |
| Wizzup | I can try to cherry-pick the changes | 22:07 |
| uvos | i mean all of these prs are really old | 22:08 |
| uvos | :P | 22:08 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/mce/pull/43 (add battery-guard module that shuts down the device on empty battery) | 22:09 |
| uvos | Wizzup: ok btw we need to configure that module | 22:09 |
| uvos | rn its off by default | 22:09 |
| Wizzup | ok | 22:09 |
| uvos | (needs per device config) | 22:09 |
| Wizzup | maybe we can make an issue for this? | 22:09 |
| uvos | Wizzup: yes | 22:09 |
| uvos | please | 22:09 |
| Wizzup | via leste-config I guess? | 22:09 |
| uvos | yes | 22:09 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/547 (leste-config: configure mce battery-guard module (needs new mce as well)) | 22:10 |
| lel | MerlijnWajer assigned an issue: https://github.com/maemo-leste/bugtracker/issues/547 (leste-config: configure mce battery-guard module (needs new mce as well)) | 22:10 |
| uvos | Wizzup: ok so #44 drops a buch of moudles no device loads | 22:10 |
| uvos | so there is accelerometer.c that we dont even build anymore and dosent work on any device and is superceeded by iio-accelerometer | 22:11 |
| Wizzup | homekey, hm | 22:11 |
| Wizzup | that is not even used on n900 is it | 22:11 |
| uvos | no | 22:11 |
| uvos | so homekey was never loaded on freemantle | 22:11 |
| uvos | and we do the funciton it was supposed to do via hildon-shortcuts | 22:12 |
| uvos | also the dbus interface it implements is no implmented by hildon-desktop | 22:12 |
| Wizzup | ok | 22:12 |
| uvos | keypad was superceeded by button-backlight | 22:12 |
| uvos | same thing but no hardcodeing of sysfs paths | 22:13 |
| uvos | and it dosent use the led engine on n900 | 22:13 |
| uvos | isntead ists software controll everywhere | 22:13 |
| uvos | but for the kbd this really dosent matter anyhow | 22:13 |
| Wizzup | ok | 22:13 |
| uvos | then there is filter-brightness-als | 22:14 |
| uvos | this is just replaced by libfilter-brightness-als-iio | 22:14 |
| Wizzup | is that also used on the n900? | 22:14 |
| uvos | yes | 22:14 |
| Wizzup | iirc I did some brightness tests last summer | 22:14 |
| Wizzup | also with the n900 | 22:14 |
| Wizzup | ok | 22:14 |
| uvos | als is the only sensor that works on n900 | 22:14 |
| Wizzup | with iio you mean | 22:14 |
| uvos | yes | 22:14 |
| uvos | with mce too | 22:15 |
| uvos | since acceleromtere.c used a sysfs interface | 22:15 |
| uvos | that is missing | 22:15 |
| uvos | and accel dosent work | 22:15 |
| uvos | becuase of udev shinaniganes | 22:15 |
| uvos | with evdev | 22:15 |
| uvos | and proximitry we broke allready | 22:16 |
| uvos | because its on evdev and we broke it with some other pr so that all the oder devices can work | 22:16 |
| uvos | we should make an issue for that if not allready | 22:16 |
| uvos | see https://github.com/maemo-leste/mce/pull/17 | 22:16 |
| uvos | and https://github.com/maemo-leste/mce/blob/master/debian/changelog | 22:17 |
| uvos | * Add iio-proximity; breaks proximity on the Nokia N900 at the moment | 22:17 |
| Wizzup | d716ea7816e29affbdbae12d124c4a92ee20f07c doesn't apply cleanly on top of master | 22:17 |
| Wizzup | both modified: Makefile | 22:17 |
| Wizzup | deleted by us: modules/display-dev.c | 22:17 |
| uvos | just drop the change to that file | 22:17 |
| Wizzup | Makefile changes seem somewhat trivial but I think they look a bit odd | 22:17 |
| Wizzup | can you check out that commit? I'll make the issue for the n900 proximity | 22:18 |
| uvos | ok sure | 22:18 |
| Wizzup | I modified https://github.com/maemo-leste/bugtracker/issues/134 | 22:20 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/mce/pull/44 (drop unused modules) | 22:23 |
| uvos | sec let me check something | 22:23 |
| uvos | ok looks fine | 22:23 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/mce/pull/44 (drop unused modules) | 22:25 |
| Wizzup | onto cmake? | 22:28 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/mce/pull/47 (Power generic) | 22:29 |
| uvos | Wizzup: no #47 and #49 | 22:29 |
| uvos | #47 is optional i gues | 22:29 |
| uvos | i just rebased it | 22:30 |
| uvos | so this one just adds the same thing as lock-generic just for power | 22:30 |
| uvos | if you load this instead of power-dsme | 22:30 |
| uvos | mce will talk to init directly | 22:30 |
| Wizzup | ok, but default is dsme | 22:30 |
| uvos | yeah | 22:30 |
| Wizzup | ok | 22:30 |
| uvos | you can have only one #define MODULE_PROVIDES "power" module loaded | 22:31 |
| uvos | and we load power-dsme in mce.ini | 22:31 |
| uvos | so this is totaly passive | 22:31 |
| Langoor | parazyd: thanks! :) | 22:32 |
| Wizzup | ok | 22:32 |
| parazyd | You're welcome | 22:32 |
| Wizzup | uvos: ok onto 47 then | 22:32 |
| uvos | this one is goning to be fun to rebase | 22:32 |
| uvos | it touches absolutly everything | 22:32 |
| uvos | so with this instead of mce just using gconf everywhere | 22:33 |
| uvos | config is provided by a module | 22:33 |
| uvos | and there are several config moudles you can load | 22:33 |
| uvos | (atm gconf and a minimal one that loads stuff from an ini file) | 22:33 |
| Wizzup | yeah, I don't think we want to change that for leste until everything else is moved over | 22:33 |
| Wizzup | but getting the code infrastructure in place is good | 22:33 |
| uvos | in future this shal have a gsettings moudule you can load | 22:34 |
| uvos | with mce_rtconf_backend_register | 22:34 |
| uvos | anyhow | 22:34 |
| uvos | let me try to rabse | 22:34 |
| uvos | rebase | 22:34 |
| Wizzup | ok | 22:34 |
| uvos | ok seams to have work | 22:47 |
| uvos | t | 22:47 |
| uvos | let me build | 22:47 |
| Wizzup | check,ty | 22:48 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/mce/pull/49 (RTconf - conf make backend runtime selectable) | 22:54 |
| uvos | Wizzup: ok should be fine now | 22:54 |
| Wizzup | merged | 22:55 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/mce/pull/49 (RTconf - conf make backend runtime selectable) | 22:55 |
| uvos | #47 is still open | 22:55 |
| Wizzup | github being weird | 22:55 |
| uvos | ok | 22:56 |
| uvos | were done here then | 22:56 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/mce/pull/47 (Power generic) | 22:56 |
| uvos | cmake well do some other time | 22:56 |
| uvos | i need to rebase | 22:56 |
| Wizzup | ok | 22:56 |
| uvos | and opean apr | 22:56 |
| Wizzup | right | 22:56 |
| Wizzup | thanks for doing all of the work & the rebasing | 22:56 |
| uvos | and we need to let all those changes sink in a bit | 22:56 |
| uvos | yw | 22:56 |
| Wizzup | so shall we build this in -devel | 22:57 |
| Wizzup | ? | 22:57 |
| uvos | yeah | 22:57 |
| Wizzup | ok | 22:57 |
| uvos | i dont expect any issues | 22:57 |
| uvos | this is now the same mce i use on maemo | 22:57 |
| Wizzup | ok | 22:57 |
| uvos | i use the cmake branch on debian only | 22:57 |
| uvos | atm | 22:57 |
| Wizzup | ok | 22:58 |
| Wizzup | well, you said you'd like this synced up for modem stuff, right? | 22:58 |
| uvos | Wizzup: right | 22:58 |
| Wizzup | amongst other things | 22:58 |
| uvos | ill get the cmake stuff tested on maemo | 22:58 |
| uvos | and then i can work on one branch | 22:59 |
| uvos | instead of having to do stuff on 2 | 22:59 |
| uvos | ill make a modem module after that | 22:59 |
| Wizzup | mce building for -devel now | 22:59 |
| Wizzup | let's see if it builds ;) | 22:59 |
| uvos | need some info on what its supposed to do / interfaces its supposed to provide for that | 22:59 |
| Wizzup | yeah, and if we use libgofono or not | 23:00 |
| uvos | i also think we shal bump mce to 1.9 with cmake :P | 23:05 |
| uvos | .128.29 is geting kinda absurd | 23:05 |
| Wizzup | probably yeah | 23:06 |
| Wizzup | we maybe should avoid conflicting with other mces if any | 23:06 |
| Wizzup | (mostly sfos) | 23:06 |
| uvos | true | 23:07 |
| uvos | Wizzup: were are not loading rtconf-gconf | 23:11 |
| uvos | rtconf-gconf needs to be the first module loaded here https://github.com/maemo-leste/mce/blob/1a761d7d0cf4194167d0bb101ff6beb5fbd1cff6/mce.ini#L17 | 23:11 |
| Wizzup | that's for leste-config, or can we do that in mce.ini ? | 23:12 |
| uvos | mce.ini | 23:12 |
| uvos | only | 23:12 |
| uvos | just prepend rtconf-gconf to the line linked above | 23:13 |
| Wizzup | uvos: built | 23:31 |
| Wizzup | uvos: on mce and modem, we should look at connui-cellular and icd2 and see what should do what | 23:40 |
| _uvos_ | Wizzup: great | 23:44 |
| Wizzup | updating on my d4 | 23:45 |
| Wizzup | not sure if this is new: 'update-rc.d: warning start or stop actions are no longer supported; falling back to defaults' | 23:48 |
| _uvos_ | hmm never seen that | 23:50 |
| _uvos_ | then again i use several de-dsme'd init scripts\ | 23:50 |
| Wizzup | I am not sure if this relates to dsme | 23:54 |
| Wizzup | this was just on apt upgrade and only charge-mode and mce were updated | 23:54 |
| parazyd | That's fine | 23:55 |
| parazyd | https://lists.debian.org/debian-devel/2013/05/msg01109.html | 23:57 |
| parazyd | In the debian/rules file you can append --no-start to dh_installinit to avoid the warning. Unsure if you want that though. | 23:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
