| Wizzup | huckg: did you manage with the bionic? | 00:00 |
|---|---|---|
| huckg | I ran down my battery and couldn't charge it because of the banjaxed state of my attempted install. | 00:01 |
| huckg | I found a bionic for $6US on ebay, today I put a charge on my battery and successfully completed step 10 of https://github.com/IMbackK/bionic-clown-boot readme. | 00:02 |
| huckg | (putting the charged battery in my old bionic). But upon rebooting it still gets stuck on a screen with 2 tux penguins at the top. | 00:04 |
| uvos | huckg: how long is it "stuck"? | 00:04 |
| uvos | what hash of droid4-kexecboot.img did you use? | 00:05 |
| huckg | sha256sum 01803c63d7f0f7dcf7e101f4a136b76c9aae5885ed458259169c93b1c6563262 | 00:06 |
| huckg | I suppose I only left it 'stuck' for maybe 5 minutes | 00:07 |
| uvos | no thats to long | 00:07 |
| huckg | let me actually time it... | 00:07 |
| uvos | your sure that you flashed that bpsw and this went of without a hitch? | 00:08 |
| huckg | Sending 'bpsw' (156 KB) OKAY [ 0.053s] | 00:08 |
| huckg | Writing 'bpsw' OKAY [ 0.340s] | 00:08 |
| uvos | 156KB? | 00:08 |
| uvos | thas wrong | 00:08 |
| uvos | should be 4MB in size | 00:09 |
| uvos | sha256sum maemo-leste-1.0-armhf-droid4-20220104.img | 00:10 |
| uvos | 6f5fbf8d45de13bac86e90848ff9017051b87682b359aee7d682d97c386032cf | 00:10 |
| uvos | somethings wrong with the downloaded image | 00:10 |
| huckg | oh, that's interesting | 00:10 |
| uvos | https://github.com/tmlind/droid4-kexecboot/blob/master/2021-01-28/droid4-kexecboot.img | 00:10 |
| huckg | Oh yeah I filed a bug report on the mismatch of the sha256sum under issues there | 00:13 |
| huckg | 8 days ago | 00:14 |
| huckg | should I try again with an earlier version? | 00:14 |
| uvos | that vession should work | 00:15 |
| uvos | and that sha256sum | 00:15 |
| uvos | is not from the file there | 00:15 |
| uvos | i just generated it form my local copy | 00:15 |
| uvos | wich works fine | 00:15 |
| uvos | but yeah no idea about the mismatch with tmlinds hash | 00:16 |
| uvos | tmlind: ^^^ could you look at this? | 00:16 |
| huckg | I got it from here: https://github.com/tmlind/droid4-kexecboot/tree/master/2021-01-28 | 00:17 |
| huckg | was that just some kind of patch rather than the whole enchilada? | 00:17 |
| uvos | no | 00:17 |
| uvos | huckg: same here i cloned that repo | 00:17 |
| uvos | and i get the above hash | 00:17 |
| uvos | and this file works fine on my bionic | 00:18 |
| uvos | so everything is fine besides the hash in the text file | 00:18 |
| uvos | but your file is only 156KB in size and has a 3rd hash | 00:18 |
| huckg | weird | 00:18 |
| uvos | so clone the repo | 00:19 |
| uvos | and use the file you get | 00:19 |
| huckg | will try that and get back to you in a few minutes, thanks. | 00:20 |
| huckg | It looks like what I previously downloaded was the webpage about droid4-kexecboot.img! | 00:33 |
| Wizzup | yikes | 00:35 |
| uvos | heh | 00:36 |
| uvos | well at least the bspw partition can read about what it should contain :P | 00:36 |
| huckg | Now do I just flash the actual file to bpsw or do I need to undo anything first? | 00:37 |
| uvos | nah just flash over | 00:37 |
| huckg | ok, now flash reboot? | 00:38 |
| uvos | yes | 00:39 |
| huckg | (I mean fastboot reboot) | 00:41 |
| uvos | sure | 00:41 |
| huckg | a screen briefly came up with some text, now I am looking at a black screen | 00:42 |
| huckg | ...with a cursor | 00:43 |
| huckg | oops, I forgot to put my sdcard back in! | 00:44 |
| uvos | so you should get the motorola logo -> penguins -> a graphical menu with some text -> sort timeout -> boots whatever entry is selected | 00:46 |
| huckg | booting! | 00:47 |
| uvos | dont try to boot the safestrap and stock android entry | 00:48 |
| uvos | that dosent work on bionic | 00:48 |
| uvos | i have a patch for that but its not in this version yet | 00:48 |
| huckg | looking at maemo-leste! | 00:49 |
| huckg | Thanks a million! It is now charging in maemo (very old battery). | 00:53 |
| Wizzup | rafael2k: looks like the built image doesn't boot | 00:53 |
| uvos | huckg: yw, sucks about the convoluted install process | 00:56 |
| uvos | huckg: locked bootloaders suck | 00:56 |
| Wizzup | rafael2k: also, what hw dev do you have? | 01:00 |
| Wizzup | rafael2k: hw rev* | 01:00 |
| huckg | Maybe I could write an idiot's guide, I seem to be well qualified. | 01:00 |
| Wizzup | :) | 01:01 |
| Wizzup | rafael2k: I get: | 01:05 |
| Wizzup | [ 4.380262] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,770): error -19 | 01:05 |
| Wizzup | [ 4.388491] Please append a correct "root=" boot option; here are the available partitions: | 01:05 |
| Wizzup | rafael2k: I can't make sense of this | 01:11 |
| Wizzup | -19 is ENODEV? | 01:12 |
| Wizzup | so what, EXT4 is enabled or something? | 01:15 |
| Wizzup | +CONFIG_EXT3_FS=y | 01:15 |
| Wizzup | +CONFIG_EXT4_FS_POSIX_ACL=y | 01:15 |
| Wizzup | .. | 01:15 |
| Wizzup | oh they make it a module later on... | 01:16 |
| Wizzup | can we just go back to our config? :( | 01:17 |
| huckg | Do I run expandcard.sh | 01:26 |
| huckg | ? | 01:26 |
| Wizzup | huckg: yeah | 01:26 |
| huckg | resize2fs: not found | 01:32 |
| Wizzup | uhh | 01:33 |
| huckg | also partprobe and fdkisk not found. First I did su and used toor as password. | 01:35 |
| Wizzup | does /sbin/resize2fs exist | 01:37 |
| huckg | then cd /etc and ./expandcard.sh | 01:37 |
| Wizzup | I usually run /etc/expandcard.sh but it probably does not matter | 01:37 |
| huckg | all of those are in /sbin | 01:38 |
| Wizzup | So you got 'resize2fs: not found' when running the script as root? | 01:39 |
| Wizzup | I guess so, it checks if it is run as root or not | 01:39 |
| Wizzup | how did you do su? | 01:40 |
| Wizzup | try 'su -' | 01:40 |
| Wizzup | or just use 'sudo -i' | 01:40 |
| Wizzup | huckg: yeah that's it I think | 01:40 |
| huckg | simply 'su' no hyphen | 01:41 |
| Wizzup | yes, that seems to not set the correct $PATH | 01:41 |
| Wizzup | the other two options as laid about work | 01:41 |
| Wizzup | laid out above* | 01:41 |
| huckg | ok, did that, it seemed to work, now device is unresponsive | 01:45 |
| huckg | on reboot stuck on KEXECBOOT screen, doesn't respond | 01:50 |
| Wizzup | I think there is an occasional hang in kexecboot where it doesn't work | 01:52 |
| Wizzup | power + volume min resets | 01:52 |
| Wizzup | (hold it) | 01:52 |
| Wizzup | I don't know why it happens on bionic, I don't have it on the droid3 kexecboot | 01:52 |
| huckg | ok, second reboot working | 01:52 |
| Wizzup | btw, there's a lot of good stuff coming to stable updates soon :) | 01:53 |
| Wizzup | much faster 2d | 01:53 |
| huckg | happy to be your guinea pig. | 01:53 |
| Wizzup | :) | 01:59 |
| Wizzup | few days | 01:59 |
| Wizzup | weird kernel build was much faster now | 03:06 |
| tmlind | freemangordon: so based on my initial quick hacks looks like adding int drm_fd to the end of struct _dbm_device and opening and using it instead of the render node for buffer allocation the related wlroots hacks can be dropped :) | 07:28 |
| tmlind | so drm_fd is looked up with drmGetPrimaryDeviceNameFromFd(dev->fd) | 07:28 |
| tmlind | maybe this issue also goes away with your planned buffer changes? | 07:29 |
| tmlind | so the issue is that some operations are not allowed for the render nodes | 07:30 |
| tmlind | anyways, will tinker more with it tonight | 07:31 |
| freemangordon | tmlind: I don;t know how those render nodes are supposed to work, so no idea if it will help | 07:41 |
| freemangordon | but, basically I plan to move to omap GEM buffers from DUMB biffers | 07:41 |
| freemangordon | that will allow me to set TILER flag on scanout buffers, which in turn shall allow setting "rotation" property on the relevant planes | 07:42 |
| rafael2k | Wizzup: kernel works, not only me using, but all mobian users... | 07:43 |
| rafael2k | Wizzup: did you copy over the new dtbs? btw, my pp is the 1.2 hw rev | 07:44 |
| rafael2k | morning! | 07:44 |
| freemangordon | rafael2k: morning! | 07:45 |
| freemangordon | tmlind: also, if we move to gbm BOs in omap DDX it may turn out that "export non-linear buffers" patch is not needed as it seems pvr_dri_support allocates directly from pvr driver for non-scanout buffers | 07:47 |
| freemangordon | tmlind: oh, and libdbm from ddk 1.9 is using omap_bo functions, I wonder why did they moved to dumb buffers later on | 07:50 |
| tmlind | freemangordon: no idea, but why do we even need libdbm? why not do this directly in mesa? | 07:55 |
| freemangordon | because of the closed pvr_dri_support blob which calls into this | 07:56 |
| tmlind | uhh | 07:56 |
| freemangordon | :) | 07:56 |
| tmlind | anyways, looks like the nastiest wlroots hack can be dropped with some libdm changes :) | 07:58 |
| tmlind | i'm now seeing display not come back up after blanking though, not sure if my changes somehow caused that | 07:59 |
| freemangordon | make sure to pull latest code as I fixed a nasty use-after-free bug I introduced with REing | 08:00 |
| tmlind | ok, need to go now, bbl | 08:00 |
| freemangordon | bbl | 08:00 |
| rafael2k | I realize the new pp kernel is already in the repo! | 09:56 |
| rafael2k | ok, initrd was not created after new kernel installed (through apt-get upgrade) | 10:03 |
| rafael2k | and yes! 5.15.10 from the repo boots fine! yay! | 10:06 |
| rafael2k | but the initrd not being automagically created and copyed to correct path needs to be fixed | 10:07 |
| rafael2k | I don't really know what happened in the recent batch of maemo updates, but I'm getting a strange 3G icon instead of 4G | 10:11 |
| rafael2k | and no strenght bars | 10:12 |
| rafael2k | Linux devuan-pinephone 5.15.10 #1 SMP Tue Jan 11 00:53:27 UTC 2022 aarch64 GNU/Linu | 10:13 |
| rafael2k | ; ) | 10:13 |
| rafael2k | but the kernel seems all good | 10:14 |
| rafael2k | so now we have telephony back to PP! with new ofono, also voice calls! | 10:19 |
| uvos | Wizzup: bionic dossent reboot with the power+vol key presses | 10:59 |
| uvos | Wizzup: none of the mapphones older than xt894 do this | 10:59 |
| rafael2k | btw, forget about the telephony icon - it all works great in latest kernel - I just was in a place without signal... | 11:21 |
| uvos | we dont use initramfs btw | 11:22 |
| rafael2k | I use | 11:22 |
| rafael2k | :P | 11:22 |
| uvos | so nessecary modules have to be built in | 11:22 |
| uvos | yeah thats why its broken | 11:22 |
| uvos | you added a kernel config | 11:23 |
| uvos | that dosent have enough modules to mount the fs | 11:23 |
| rafael2k | sure | 11:23 |
| uvos | and work around it with initramfs | 11:23 |
| rafael2k | initramfs has all the modules to boot | 11:23 |
| rafael2k | this is why it exists in the first place... | 11:23 |
| rafael2k | why no initd, btw? | 11:24 |
| uvos | this makes sense on x86 pcs | 11:24 |
| uvos | where you have one kernel for very different hw | 11:24 |
| uvos | so a image with all the modules needed to get to mounting the fs is large | 11:24 |
| rafael2k | this is the idea for arm too | 11:24 |
| rafael2k | with device trees, dtbs and so on | 11:24 |
| uvos | with a kernel that only works for one device anyhow its not needed | 11:24 |
| rafael2k | there are many reasons of why to use a kernel module, but anyway, got it | 11:25 |
| rafael2k | so some modules need to be sneaked in with 'y' | 11:26 |
| uvos | yes | 11:26 |
| Wizzup | uvos: oh | 11:26 |
| rafael2k | and I'll need to update my boot.txt | 11:26 |
| Wizzup | rafael2k: we do not have an initrd in our package, which is why the previous kernel failed | 11:27 |
| Wizzup | rafael2k: it must work without initrd or we need to make initrd | 11:27 |
| rafael2k | did not failed for me :P | 11:27 |
| Wizzup | yes because I rebuilt and fixed the package so that EXT4 is built in | 11:27 |
| Wizzup | it was a module and therefore my pinephone can't mount its rootfs atm | 11:27 |
| rafael2k | nope, I just created an initrd | 11:27 |
| Wizzup | that's not the point | 11:28 |
| rafael2k | anyway, easy pizzy | 11:28 |
| Wizzup | 'apt dist-upgrade' gives nobody an initrd on leste | 11:28 |
| rafael2k | I did not know that, sorrio | 11:28 |
| Wizzup | so any upgrade will break if the required modules aren't built in | 11:28 |
| Wizzup | does the current kernel package work without initrd for you? | 11:28 |
| Wizzup | (M iade ext4 built in) | 11:28 |
| Wizzup | I made* | 11:28 |
| rafael2k | I dunno, I was always creating an initrd | 11:28 |
| rafael2k | but it is not only ext4 right? | 11:29 |
| rafael2k | how would one use use a luks root fs this? | 11:29 |
| rafael2k | then you would need crypto stuff too, md stuff, and so on | 11:30 |
| Wizzup | I don't know what else besides ext4 is required to boot | 11:30 |
| Wizzup | luks is always done with an initrd | 11:30 |
| rafael2k | it depends on the use case | 11:30 |
| Wizzup | I am not -against- an inird but we never needed it up to this point, and ext4 being a module is not a good reason | 11:30 |
| Wizzup | of course when we add luks support, we will need them | 11:30 |
| rafael2k | ok, I don't really see the point in not truggering update-initrd after a kernel upgrade | 11:30 |
| rafael2k | but it is an easy change anyway | 11:31 |
| Wizzup | are those scripts even installed in leste pp? | 11:31 |
| rafael2k | I'd like to see my root fs ciphered soon | 11:31 |
| rafael2k | yes | 11:31 |
| Wizzup | I am not so sure they are on mine, because I don't think an initrd was made | 11:31 |
| uvos | non | 11:31 |
| uvos | no they arnt | 11:31 |
| Wizzup | you probably just did something to your image to get it rafael2k | 11:32 |
| rafael2k | lemme see the packages | 11:32 |
| rafael2k | no | 11:32 |
| rafael2k | all from the repo | 11:32 |
| Wizzup | our repo is debian :) | 11:32 |
| rafael2k | my system is clean | 11:32 |
| rafael2k | yeap | 11:32 |
| Wizzup | initrd will require us to think a lot of things through that we're not really ready for I think, so we've been postponing that until we really need it | 11:33 |
| rafael2k | initramfs-tools initramfs-tools-core cryptsetup cryptsetup-initramfs | 11:33 |
| rafael2k | with this I have luks up and running | 11:34 |
| Wizzup | ok, but this is not installed by default | 11:34 |
| rafael2k | but it could, right? in case we want to add security as an option | 11:35 |
| Wizzup | 11:33 < Wizzup> initrd will require us to think a lot of things through that we're not really ready for I think, so we've been postponing that until we really need it | 11:35 |
| rafael2k | which things exactly? | 11:35 |
| Wizzup | let's see "can we do luks" separate from "get proper pine64 kernel" | 11:35 |
| rafael2k | sure!! | 11:35 |
| rafael2k | and one step of the other | 11:35 |
| rafael2k | ; ) | 11:35 |
| Wizzup | I am pulling the new image now on a fresh image with -devel added | 11:36 |
| Wizzup | let's see if I get an initrd | 11:36 |
| rafael2k | I can test here too | 11:36 |
| rafael2k | without any manual intervention | 11:36 |
| Wizzup | the thing with luks and initrd is that we might even want some ui in there, touchscreen, on screen keyboard to enter unlock codes, etc | 11:37 |
| Wizzup | and we also need to think about alarms, other stuff | 11:37 |
| Wizzup | so I doubt it'll be as simple as installing 'cryptsetup-initramfs' | 11:37 |
| Wizzup | also we have various modes we (can) boot to like recovery mode with on screen keyboard | 11:37 |
| rafael2k | now with hardware keyboard in the pine, already supported by the kernel... | 11:37 |
| Wizzup | I don't have a hw keyboard for mine yet, and our general solution should work for devices without hw keyboard | 11:38 |
| Wizzup | (mine is being shipped, but yeah) | 11:38 |
| rafael2k | if you want luks, find yourself a keyboard, or copy the initd from postmarket OS (which has on-screen keyboard and so on to unlock luks rootfs) | 11:38 |
| Wizzup | no, I want luks the proper way :P | 11:38 |
| Wizzup | that was not the point | 11:39 |
| rafael2k | the standard way is the proper way | 11:39 |
| rafael2k | :P | 11:39 |
| bencoh | wait, what would be the proper way? | 11:39 |
| rafael2k | yeap | 11:39 |
| Wizzup | well then I guess you can run xfce on your phone and hope for the best :P | 11:39 |
| rafael2k | luks is support for long time in debian, I just for decades | 11:40 |
| rafael2k | it works fine as it | 11:40 |
| rafael2k | *as is | 11:40 |
| Wizzup | I think we are miscommunication very often | 11:40 |
| bencoh | Wizzup: how do you expect it to boot with a luksed rootfs and no initrd? | 11:40 |
| Wizzup | bencoh: I did not say that | 11:40 |
| bencoh | I thought so as well, but then ... what's the proper way? (or rather, what isn't the proper way?) | 11:41 |
| Wizzup | rafael2k: I am not questioning how well luks works in debian, I am saying that I don't think a tty and 'use hw keyboard' is a good way, some on screen keyboard is required, and probably way more integration | 11:41 |
| Wizzup | rafael2k: so whether and how debian supports it is not super relevant, debian is built for servers | 11:41 |
| Wizzup | bencoh: well clearly with initrd, but not just 'oh copy this initrd from source X' :) | 11:41 |
| bencoh | ah :) | 11:41 |
| bencoh | I wonder if a framebuffer app would cut it | 11:42 |
| Wizzup | how would maemo alarm work? | 11:42 |
| rafael2k | Wizzup: Debian is built for server? Did not know that. :P | 11:43 |
| bencoh | Wizzup: ah, right | 11:43 |
| rafael2k | btw, I can work in copying over the on-screen keyboard from PmOS | 11:43 |
| Wizzup | rafael2k: still kernel does not boot for me | 11:43 |
| bencoh | meaning we'd need a fullblown xorg-capable initrd anyway | 11:43 |
| rafael2k | when we have the more urgent stuff settle down | 11:43 |
| Wizzup | bencoh: yes | 11:43 |
| bencoh | (not just xorg-capable, but hildon-capable) | 11:43 |
| bencoh | sounds like a lot tbh | 11:43 |
| Wizzup | bencoh: well there are other things we can do, but these are things to consider when I say "I want luks the proper way" | 11:44 |
| bencoh | yeah | 11:44 |
| rafael2k | bencoh: x on initrd? no | 11:44 |
| Wizzup | layman translation would be "I don't want to miss my flight because my phone was stuck in on screen keyboard to unlock my luks partition and thus could not make an alarm sound" | 11:44 |
| bencoh | :] | 11:44 |
| Wizzup | rafael2k: ok now both my pinephone sd cards are bricked wrt kernel | 11:45 |
| rafael2k | Wizzup: you need to light a candle | 11:45 |
| Wizzup | we could have the pinephone use debian initrd I suppose, but it could get in the way of many things | 11:45 |
| Wizzup | like probably it will come with systemd in the initrd | 11:45 |
| rafael2k | I don't really get this maemo stack part | 11:45 |
| bencoh | either that, or add a tiny framebuffer-only alarm app for actdead/alarm-mode | 11:45 |
| Wizzup | that can mess up things for us | 11:45 |
| rafael2k | what is this alarm thing you are talking about? | 11:46 |
| uvos | rafael2k: phone is off | 11:46 |
| uvos | rafael2k: alarm fires | 11:46 |
| uvos | rafael2k: what happens? | 11:46 |
| uvos | rafael2k: phone is off | 11:46 |
| bencoh | (alarm, as in, wakeup-wakeup-time-to-wakeup) | 11:46 |
| uvos | rafael2k: user plugs in usb charger | 11:47 |
| uvos | rafael2k: what happens? | 11:47 |
| Wizzup | rafael2k: care to send over the initrd you made for the latest kernel pkg | 11:47 |
| uvos | yes replacing the mess of "actdead" with small framebuffer applicatiosn is something imo we need to do | 11:48 |
| uvos | its also what im doing allreay | 11:48 |
| uvos | see charge-mode | 11:48 |
| Wizzup | well that could work, but there are also other ways to do deal with it | 11:48 |
| Wizzup | there could also be a (read-only by default, forced by crypto) partition which we boot from | 11:48 |
| Wizzup | I think the chromebooks use some dm thing for this - dm verity? | 11:49 |
| uvos | i gues, but the way actdead is implemented its pretty terrible, so reimplementing how it works is a good thing | 11:49 |
| Wizzup | I think this is unrelated to how actdead works | 11:49 |
| uvos | sure | 11:49 |
| uvos | you could place small framebuffer application(s) into readonly rootfs | 11:50 |
| Wizzup | rafael2k: so point is that "phone is not a server and fullfills some other needs that typical initrd does not deal with" | 11:50 |
| Wizzup | rafael2k: could you send me the initrd from your device so that I can maybe rescue one of my devices? | 11:50 |
| Wizzup | uvos: or X if we are lazy and want to re-use code | 11:50 |
| uvos | yes but the curreny code is a huge maintiance bruden because its so bad | 11:51 |
| uvos | (spread over all of the deamons) | 11:51 |
| uvos | with if(actdead) changing deamon behavior | 11:51 |
| Wizzup | we don't even have alarms working yet, I think because of pulseaudio setup | 11:51 |
| Wizzup | I don't know if it's that bad really, but I haven't looked at it in a while | 11:52 |
| Wizzup | btw dm-verity: https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html - for any real threat model we'd probably want the key to check against in some hsm but nevermind that | 11:52 |
| Wizzup | (for now) | 11:53 |
| uvos | Wizzup: it really is that terrible, so it works by having the entire stack runing, changings its behavior all over the place, this is really bad allready beacuse this means that actdead implementation (a mode that really dosent do mutch at all) is spread over manny manny thousands of lines of code for no reason. then it causes a masive burdon of code in all of these unrelated applications that cant really be tested, because you cant | 11:57 |
| uvos | just test these codepaths in a single deamons in isolation so you have to spin up actdead on the entire device an poke around, but good luck finding bugs because all of these deamons in freshly untested codepaths interact via dbus so who knows who causes what. | 11:57 |
| uvos | its basicly as bad as the entrie rest of the system in complexity | 11:57 |
| uvos | for providing functionality that could be in a 1klock frambuffer application | 11:58 |
| Wizzup | yeah, I'm not saying we should do this for alarm, I mostly do not have a grasp on the complexity of it so will refrain from commenting | 12:00 |
| uvos | not to even mention the insanity of booting all the way to x with most deamons runing just to display a battery icon | 12:00 |
| Wizzup | I think first steps alarm wise is to make sure that our audio setup works the way it expects (with roles) and then see if normal alarms (nevermind 'wake-to-alarm') works | 12:01 |
| uvos | normal alarms work in the sense that alarm mode is enterd and the alarm shows up | 12:01 |
| uvos | so dose wake to alarm btw | 12:02 |
| uvos | except that rtc isent set | 12:02 |
| uvos | everything else is in place | 12:02 |
| Wizzup | uvos: sounds also don't work | 12:02 |
| uvos | (except also that it boots to hildon and shows the alarm there ofc) | 12:02 |
| uvos | yes | 12:02 |
| Wizzup | and the vibration doesn't work because the sound doern't work | 12:02 |
| uvos | yes | 12:02 |
| uvos | i mean it goes thrugh the motions mostly | 12:02 |
| Wizzup | right | 12:02 |
| Wizzup | freemangordon: ftr looks like normal mc places accounts in $HOME/.local/share/telepathy/mission-control/accounts.cfg | 12:10 |
| Wizzup | vs $HOME/.rtcom-accounts on fremantle | 12:11 |
| Wizzup | I bet that noia patched mc to read from that dir | 12:11 |
| Wizzup | nokia* | 12:11 |
| uvos | seams like mostly nonsese obfuscation or? | 12:12 |
| Wizzup | I wouldn't go so far to say thatr | 12:13 |
| Wizzup | I'm just trying to understand who stores what, reads/writes what to where | 12:13 |
| uvos | ok | 12:13 |
| Wizzup | the file format/config is exactly the same, so it looks like just a changed path | 12:13 |
| Wizzup | fremantle also has accounts.cfg in .rtcom-accounts | 12:13 |
| Wizzup | so this means that probably indeed telepathy and mc (mission-control) manage accounts for us, and rtcom doesn't do special things there to 'register' accounts or something | 12:14 |
| Wizzup | I mean rtcom clearly does some things in conversations and calls ui, but they don't add accounts to telepathy by parsing .rtcom-accounts/accounts.cfg for example | 12:14 |
| Wizzup | which is good to know conceptually | 12:14 |
| uvos | sure | 12:15 |
| rafael2k | Wizzup: entered in a working meeting - come back soon | 12:37 |
| Wizzup | np | 12:38 |
| Wizzup | uvos: do you think we're ready to start pushing 5.15 to stable? | 12:54 |
| Wizzup | I think there might be -some- issues we haven't run into yet in -devel, but otherwise we're pretty good? | 12:54 |
| Wizzup | freemangordon: same question to you^ | 12:55 |
| Wizzup | I suppose I should test one more "download latest image" and try "apt dist-upgrade" to -devel type of action | 12:55 |
| uvos | i hangs often for me | 13:12 |
| uvos | its allways pretty stable @home | 13:12 |
| uvos | as soon as i take it outside it starts rebooting every 10 minutes or so if in use in any way (audio etc) | 13:12 |
| Wizzup | really? | 13:13 |
| uvos | yeah | 13:13 |
| Wizzup | on the droid4? | 13:13 |
| uvos | yeah | 13:13 |
| Wizzup | interesting... | 13:13 |
| Wizzup | I really haven't seen any resets/hangs for a week+ | 13:13 |
| uvos | something with wlan | 13:13 |
| Wizzup | maybe longer | 13:13 |
| Wizzup | right, the "microwave bug" :p | 13:14 |
| uvos | if you rmmod it its stable i think | 13:14 |
| uvos | at least stable is | 13:14 |
| uvos | *ish | 13:14 |
| uvos | it still reboots sometimes | 13:14 |
| uvos | but it dose that @home too | 13:14 |
| uvos | once every couple of days | 13:14 |
| rafael2k | Wizzup: http://abradig.org.br/pinephone/initrd.img-5.15.10 | 13:26 |
| Wizzup | did you also adjust boot.txt? | 13:28 |
| rafael2k | well, I copy this file to the default initrd image as specified in boot.txt | 13:30 |
| Wizzup | ok let me try | 13:31 |
| rafael2k | if you change boot.txt, remember to re-create the boot.scr | 13:32 |
| rafael2k | mkimage -A arm -O linux -T script -C none -a 0 -e 0 -d boot.txt boot.scr | 13:32 |
| Wizzup | so | 13:32 |
| Wizzup | 13:30 < rafael2k> well, I copy this file to the default initrd image as specified in boot.txt | 13:32 |
| Wizzup | # ls | 13:32 |
| Wizzup | allwinner config-5.15.10 lost+found vmlinuz-5.15.10 | 13:32 |
| Wizzup | boot.scr Image.gz System.map-5.15.10 | 13:32 |
| Wizzup | where is this default initrd image? | 13:32 |
| Wizzup | (it is not there in our pinephone images) | 13:33 |
| rafael2k | look at the config | 13:33 |
| rafael2k | if not, just add it | 13:33 |
| Wizzup | also our boot.scr doesn't contain a reference to an initrd | 13:33 |
| rafael2k | of course it is not... as you just explained me why | 13:33 |
| rafael2k | :P | 13:33 |
| Wizzup | yes, but you said 'I copy this file to the default initrd image as specified in boot.txt' | 13:33 |
| Wizzup | which seems to suggest that we already have it in our boot.txt | 13:34 |
| Wizzup | I also don't have a boot.txt | 13:34 |
| Wizzup | see, I am just trying to understand what I need to change to go from "this works for me" to "this works for everyone" | 13:34 |
| Wizzup | so I need to understand the explicit steps :) | 13:34 |
| Wizzup | so what is the option in boot.txt? | 13:34 |
| rafael2k | right | 13:34 |
| rafael2k | lemme put my boot.txt: | 13:34 |
| rafael2k | well... it was not me who removed initrd support from maemo | 13:35 |
| rafael2k | :P | 13:35 |
| rafael2k | btw, dont you have update-initramfs ? | 13:36 |
| Wizzup | you're turning the world upside down | 13:37 |
| Wizzup | before this new kernel I build we never had an initrd and never needed it | 13:37 |
| Wizzup | so it was not "removed" by me | 13:37 |
| Wizzup | rafael2k: the system doesn't *boot*, how am I supposed to run it | 13:37 |
| rafael2k | http://abradig.org.br/pinephone/boot.txt | 13:37 |
| Wizzup | ty | 13:37 |
| Wizzup | this is a very different boot.txt from what we ship | 13:37 |
| rafael2k | you can use just the code from line: | 13:38 |
| rafael2k | setenv bootargs console=tty0 console=${console} root=/dev/mmcblk0p2 rw rootwait rootfstype=ext4 fbcon=rotate:1 | 13:38 |
| rafael2k | until line: | 13:38 |
| rafael2k | fi; (the last before the final fi | 13:38 |
| Wizzup | I understand | 13:38 |
| rafael2k | btw, this also can be used as the scheleton for the multi-boot boot.txr | 13:38 |
| rafael2k | *boot.txt | 13:38 |
| rafael2k | edit the boot.txt, and do the mkimage | 13:39 |
| rafael2k | Wizzup: this is why multi-boot is good | 13:40 |
| rafael2k | ; ) | 13:40 |
| rafael2k | if one does not boot, boot the other system | 13:40 |
| Wizzup | much better is not to break the system | 13:41 |
| rafael2k | totally agree | 13:41 |
| rafael2k | The system is broken for more than one year | 13:42 |
| rafael2k | we are trying to unbreak, right? | 13:42 |
| Wizzup | we're trying to fix bugs yes, it was not usually in an unbootable state, but this is fine, it's -devel anyway | 13:42 |
| Wizzup | I'm just trying to understand we never "removed" initrd, it was just never necessary | 13:42 |
| Wizzup | so saying "it was not me who removed initrd from maemo" is just weird | 13:43 |
| rafael2k | Im just kidding | 13:43 |
| Wizzup | it's booting now btw | 13:43 |
| Wizzup | ok | 13:43 |
| Wizzup | uvos: heh I am greeted by salutem | 13:43 |
| Wizzup | rafael2k: so we have two options: (1) we make a less bloated config and also remove all the parts where we make the stuff that we need modules (this could just be removing some mobian patches) or (2) we have pine64 kernel package depend on initrd tools and hope the stuff runs automatically | 13:44 |
| Wizzup | (2) also means we have to update our uboot package | 13:44 |
| Wizzup | If we do (2) the nice thing is we can just piggy back on mobian kernel, which is fine by me | 13:45 |
| rafael2k | Is the config bloated? | 13:45 |
| rafael2k | I don't get it | 13:45 |
| Wizzup | debian configs usually are bloated yeah | 13:46 |
| rafael2k | wait | 13:46 |
| rafael2k | you was saying about booting | 13:46 |
| rafael2k | now about bloat? | 13:46 |
| Wizzup | it's the same thing: we need to change the pine64_config | 13:46 |
| rafael2k | same thing? | 13:46 |
| rafael2k | hum | 13:46 |
| rafael2k | ok | 13:46 |
| rafael2k | I don't see any bloat tbh | 13:46 |
| rafael2k | it is just a pretty standard setup | 13:47 |
| rafael2k | does it harm? | 13:47 |
| Wizzup | ultimately yes, but it's not particularly important now | 13:47 |
| rafael2k | I thought we just needed to add some modules as static and voila | 13:47 |
| Wizzup | the kernel build took like 4 hours yesterday | 13:47 |
| rafael2k | yes? | 13:47 |
| Wizzup | as opposed to like 1hr for droid4 | 13:47 |
| Wizzup | but it seems to vary, so idk | 13:48 |
| rafael2k | of course yes... not having half of the functionalities of linux - definitelly | 13:48 |
| Wizzup | yeah so if we want to go for (1) then we need to figure out what stuff needs to be built in | 13:48 |
| rafael2k | ok | 13:48 |
| Wizzup | yesterday I tried to just make EXT4 builtin, but that wasn't enough to make it boot | 13:48 |
| rafael2k | I can do that | 13:48 |
| rafael2k | I'll try to do it today at night, after baby goes sleep | 13:48 |
| Wizzup | I would really appreciate that if you can, we could just add another patch on top of the mobian patches to changef pine64_defconfig | 13:49 |
| Wizzup | awesome | 13:49 |
| rafael2k | sure | 13:49 |
| Wizzup | if that ends up being too frustration, we can go for (2) as far as I am concerned | 13:49 |
| rafael2k | no no | 13:49 |
| rafael2k | lets do the fast track now | 13:49 |
| Wizzup | re: bloat, you're right the on-disk is about the same d4 and pine64, so maybe the raspi build setup was just struggling more initially | 13:49 |
| rafael2k | to have everything up and running | 13:49 |
| rafael2k | just set some 'y' and that is it | 13:50 |
| Wizzup | ok so you want me to install initramfs-tools ? | 13:50 |
| Wizzup | wait, I don't understand | 13:50 |
| Wizzup | what is "fast track"? | 13:50 |
| rafael2k | just edit the config | 13:50 |
| rafael2k | and have a kernel config which boots without initrd | 13:50 |
| rafael2k | as is in maemo right nnow | 13:50 |
| Wizzup | ok, and you can take a look at that? | 13:50 |
| rafael2k | yes | 13:50 |
| Wizzup | ok, ty | 13:50 |
| rafael2k | I come back later | 13:51 |
| rafael2k | lemme know about ofono too | 13:51 |
| rafael2k | if there are any questions, lemme know | 13:51 |
| rafael2k | I saw updated sphone | 13:51 |
| rafael2k | cool! | 13:51 |
| Wizzup | looks like I had initramfs-tools already installed, so why did it not run... hm | 13:54 |
| freemangordon | Wizzup: I am not sure I can help with mc/tp stuff, it passed more then an year I played with it | 14:14 |
| freemangordon | re kernel - do you still see xorg crashes after latest patch? | 14:14 |
| freemangordon | BTW I had very strange behaviour twice, in different ways | 14:15 |
| Wizzup | no, I have not seen X crashes | 14:15 |
| freemangordon | first time device was in my pocket with this maps application searchiong for gps | 14:16 |
| freemangordon | maybe 30 minutes later as was unable to unlock the device - swiping tklock slider was doing nothing | 14:16 |
| Wizzup | the latter sounds like the drm thing I ran into | 14:17 |
| Wizzup | or did tklock show for you? | 14:17 |
| freemangordon | yes, it was there | 14:17 |
| freemangordon | and wotking | 14:17 |
| freemangordon | I was able to swite the slider | 14:17 |
| Wizzup | the power button might trigger more easily | 14:17 |
| freemangordon | hmm? | 14:17 |
| freemangordon | power button triggers tklock | 14:18 |
| Wizzup | I was thinking about the maps app | 14:18 |
| Wizzup | not sure about either bugs | 14:18 |
| Wizzup | I don't think I have seen those beforfe | 14:18 |
| freemangordon | me neuther | 14:18 |
| freemangordon | *neither | 14:18 |
| freemangordon | either mce or systemui was misbehaving | 14:18 |
| uvos | never seen that befor either | 14:18 |
| uvos | then again i dont use tklock | 14:19 |
| uvos | yeah that sounds like systemui and mce got out of sync | 14:19 |
| uvos | global state flags wise | 14:19 |
| uvos | maybe mce crashed | 14:19 |
| freemangordon | but, given that systemui/tklock have not been changed since long time ago I would say mce got out of sync, somehow | 14:19 |
| freemangordon | could be | 14:19 |
| uvos | and got restarted | 14:19 |
| uvos | then its in the wrong state | 14:19 |
| freemangordon | mce should unlock the device on start | 14:20 |
| freemangordon | at least this was the behaviour back then | 14:20 |
| uvos | sure, it dose | 14:20 |
| freemangordon | not really as eventually I had to har-reset (power+vol) | 14:20 |
| freemangordon | *hard-reset | 14:20 |
| uvos | well it dose internally | 14:21 |
| uvos | so probubly not a crash then | 14:21 |
| freemangordon | mhm | 14:21 |
| freemangordon | another very weird thing that happened is something with touchscreen | 14:21 |
| uvos | it dident work? | 14:21 |
| uvos | thats hw bug | 14:21 |
| uvos | also happens on android | 14:21 |
| freemangordon | could be | 14:21 |
| freemangordon | happened only once | 14:22 |
| freemangordon | it was semi-working | 14:22 |
| freemangordon | like some touches were registered some not | 14:22 |
| uvos | hw bug | 14:22 |
| freemangordon | could be | 14:22 |
| uvos | very sure | 14:22 |
| freemangordon | I am reporting re Wizzup's question if we shall push to -stable | 14:22 |
| freemangordon | and the most annoying thing is that charging stuff | 14:23 |
| uvos | right and a hw bug is no reason not to | 14:23 |
| freemangordon | sure | 14:23 |
| Wizzup | :) | 14:23 |
| uvos | the charging stuff is fine for me | 14:23 |
| uvos | except the ocassional delay | 14:23 |
| freemangordon | not for me | 14:23 |
| uvos | so whats the probel exacly | 14:24 |
| uvos | please describe in extream detail | 14:24 |
| freemangordon | that occasional delay happens 90% if not more of the cases here | 14:24 |
| freemangordon | sec | 14:24 |
| freemangordon | after I plug a cable, led turns green, but no charging notification is giver neither battery icon is animated | 14:25 |
| freemangordon | no idea what the 'delay' you talk about is, but it sits like that here forever | 14:25 |
| uvos | havent seen that | 14:26 |
| uvos | but ok | 14:26 |
| freemangordon | happens every time | 14:26 |
| uvos | same bug as the 30s delay | 14:26 |
| freemangordon | do you want me to provide some logs? | 14:26 |
| uvos | can you check sysfs in this state? | 14:26 |
| freemangordon | sure | 14:27 |
| freemangordon | what in particular? | 14:27 |
| uvos | freemangordon: so please: | 14:28 |
| uvos | cat /sys/class/power_supply/battery/uevent | 14:28 |
| uvos | udevadm monitor | 14:28 |
| uvos | plug in usb | 14:28 |
| uvos | cat /sys/class/power_supply/battery/uevent | 14:28 |
| uvos | pastbin output | 14:28 |
| freemangordon | ok, now I have the cable disconnected and battery icon is animated :) | 14:30 |
| freemangordon | so I am nit sure I can do what you want me to | 14:30 |
| uvos | do the above | 14:30 |
| freemangordon | oh, it is even better | 14:30 |
| uvos | and note the state of the gui inidcator at eatch step | 14:31 |
| freemangordon | if I plug the cable, battery animation stops | 14:31 |
| freemangordon | ok, now I have cable connected and no animation, sec will provide the output | 14:31 |
| freemangordon | uvos: https://pastebin.com/nVHdcwLY | 14:32 |
| uvos | please do as i say | 14:32 |
| uvos | 1. usb unplugged | 14:32 |
| uvos | 2. note inidcator | 14:32 |
| uvos | 3. cat /sys/class/power_supply/battery/uevent | 14:32 |
| uvos | 4. udevadm monitor | 14:32 |
| freemangordon | this is what I did, no? | 14:33 |
| uvos | 5 . plug in usb | 14:33 |
| freemangordon | besides udevadm | 14:33 |
| uvos | 6. cat /sys/class/power_supply/battery/uevent | 14:33 |
| uvos | plese provide all steps | 14:33 |
| uvos | otherwise its useless | 14:33 |
| uvos | also what state is this pastebin even | 14:33 |
| freemangordon | (15,31,24) freemangordon: ok, now I have cable connected and no animation, sec will provide the output | 14:33 |
| freemangordon | (15,31,57) freemangordon: uvos: https://pastebin.com/nVHdcwLY | 14:33 |
| uvos | ui inidcator and usb plug state wise | 14:33 |
| freemangordon | ok will do it from start | 14:33 |
| uvos | ok so upower got out of sync | 14:34 |
| uvos | also check upower -d for state | 14:34 |
| uvos | (this is probubly going to be wrong | 14:34 |
| uvos | ) | 14:34 |
| uvos | while sysfs is correct | 14:34 |
| freemangordon | state: discharging | 14:35 |
| freemangordon | that's upower -d | 14:35 |
| uvos | yeah so upower drops the ball somewhere since uevent is correct | 14:35 |
| uvos | this is pretty mutch what i know allready | 14:35 |
| uvos | it being in uevent file without the kernel having issued the corrisponding uevent event is impossible | 14:36 |
| freemangordon | shall I restart upower with some verbosity? | 14:36 |
| uvos | yeah | 14:36 |
| uvos | also udevadm monitor | 14:36 |
| uvos | just to be sure | 14:36 |
| freemangordon | ok | 14:36 |
| freemangordon | uvos: on cable being plugged https://pastebin.com/iE2FxYNF | 14:37 |
| uvos | again with udevadm monitor -p -k | 14:39 |
| uvos | please | 14:39 |
| freemangordon | upower -m https://pastebin.com/8YXP6m5y on plug | 14:39 |
| freemangordon | ok | 14:39 |
| freemangordon | ugh | 14:40 |
| tmlind | freemangordon: your mesa changes dropped PVRDRIQueryDmaBufFormats PVRDRIQueryDmaBufModifiers PVRDRIQueryDmaBufFormatModifierAttribs, are these not implemented in the firmware or dropped by accident? | 14:40 |
| freemangordon | not implemented | 14:40 |
| freemangordon | uvos: https://pastebin.com/19aGm7D7 | 14:40 |
| uvos | hmm | 14:41 |
| uvos | something is wrong here | 14:41 |
| freemangordon | uvos: I don't think this is upower problem :) | 14:41 |
| uvos | yeah | 14:41 |
| freemangordon | POWER_SUPPLY_STATUS=Discharging | 14:41 |
| uvos | but thats really wierd | 14:41 |
| uvos | since the kernel has it as the last set porparty | 14:41 |
| uvos | in the uevent file | 14:41 |
| uvos | hmm | 14:42 |
| tmlind | freemangordon: if dmabuf modifiers are not implemented then we need to also do what xcracer did and not advertise EXT_image_dma_buf_import_modifiers at all, at least wlroots will bail out otherwise | 14:42 |
| freemangordon | tmlind: I don't think this is adretised | 14:43 |
| freemangordon | oh, it is :( | 14:43 |
| freemangordon | why? | 14:43 |
| tmlind | freemangordon: maybe that commit got accidentally reverted, see 4f851d108e8f ("egl_dri2: Don't expose EXT_image_dma_buf_import_modifiers") | 14:43 |
| uvos | freemangordon: wierd | 14:44 |
| freemangordon | no, changing DRI_IMAGE version should prevent this being advertised | 14:44 |
| uvos | freemangordon: i also cant repoduce the problem | 14:44 |
| freemangordon | uvos: ok, but this happens every time | 14:44 |
| freemangordon | which kernel? | 14:44 |
| uvos | leste | 14:44 |
| uvos | devel | 14:44 |
| uvos | with my patch ofc | 14:44 |
| freemangordon | Linux devuan-droid4 5.15.2 #1 SMP PREEMPT Sat Jan 8 23:05:00 UTC 2022 armv7l GNU/Linux | 14:44 |
| uvos | yeah | 14:45 |
| freemangordon | tmlind: gimme some time to finish what we do with uvos and I'll have a look | 14:45 |
| tmlind | freemangordon: yeah sure no hurry, just wondering.. maybe DRM_IMAGE version gets checked too late when using the extension | 14:46 |
| tmlind | anyways, so i got wlroots working with pretty much just xcracer's modified patch for GL_EXT_unpack_subimage only :) | 14:47 |
| freemangordon | uvos: but "POWER_SUPPLY_STATUS=Charging" in /sys/class/power_supply/battery/uevent | 14:48 |
| uvos | freemangordon: wierd | 14:48 |
| freemangordon | oh | 14:49 |
| uvos | im also not sure how my patch breaks it | 14:49 |
| freemangordon | sec | 14:50 |
| uvos | since it seams to report it the same way | 14:50 |
| freemangordon | yeah, I don;t think it is your patch really | 14:50 |
| freemangordon | see https://pastebin.com/ubj52RAX | 14:50 |
| freemangordon | the first event, but this is on unplug | 14:50 |
| freemangordon | so, "charging" comes on unplug | 14:51 |
| uvos | what about it? | 14:51 |
| uvos | its the wrong way around | 14:51 |
| freemangordon | yes | 14:51 |
| uvos | and uevent contains the right value | 14:51 |
| uvos | i know this is the problem but not sure how that can happen | 14:52 |
| freemangordon | maybe udev does not read the events properly | 14:52 |
| uvos | seams kinda unlikley | 14:52 |
| uvos | conisdering how mutch stuff would not work then | 14:52 |
| freemangordon | well, then kernel does not send them properly | 14:52 |
| uvos | right - somehow | 14:52 |
| tmlind | or sends the events wrong way around with charge vs drain voltage direction confused? | 14:53 |
| uvos | yeah but its fine in sysfs, so the values in cpcap-charger are fine | 14:53 |
| uvos | they must be bouncing or something | 14:53 |
| tmlind | ok | 14:53 |
| freemangordon | uvos: which patch is that? https://github.com/maemo-leste/droid4-linux/commits/wip/n900/maemo-5.15-cleaned-up | 14:54 |
| uvos | https://github.com/maemo-leste/droid4-linux/commit/549645980ae302c6b13f62e29715420a08b87bb2 | 14:54 |
| freemangordon | hmm, POWER_SUPPLY_CHARGE_COUNTER=-3676 | 14:54 |
| freemangordon | how's that possible? | 14:54 |
| uvos | thats fine | 14:54 |
| uvos | fine | 14:54 |
| freemangordon | ok | 14:55 |
| uvos | it starts at 0 at boot | 14:55 |
| uvos | no matter what the battery state is | 14:55 |
| uvos | and gows down | 14:55 |
| uvos | with discarge ofc | 14:55 |
| tmlind | freemangordon: fyi for later on when you get a chance, here's what i did to get wlroots working with your dbm http://muru.com/linux/d4/0001-dbm-Fix-render-node-usage-for-wlroots.patch | 14:55 |
| freemangordon | tmlind: ok | 14:57 |
| freemangordon | uvos: and what about POWER_SUPPLY_POWER_AVG=-1690929 | 14:57 |
| freemangordon | is that ok to be negative? | 14:57 |
| uvos | yes | 14:57 |
| uvos | that means discharging | 14:58 |
| freemangordon | ok | 14:58 |
| uvos | er charging | 14:58 |
| uvos | negative numbers there mean charging | 14:58 |
| tmlind | does that match also on other hardware like n900? | 14:58 |
| freemangordon | never seen negative average power | 14:59 |
| uvos | yes it matches the expecations of maemo | 14:59 |
| tmlind | ok | 14:59 |
| uvos | since if it drops above 0 | 14:59 |
| uvos | and usb is plugged in the baner shows up | 14:59 |
| uvos | to warn you device is using more power than can be supplyed by usb or something | 14:59 |
| freemangordon | uvos: ok, so it seems no events are missing, it is just that kernel sends wrong state on device chage | 14:59 |
| uvos | right | 15:00 |
| uvos | not sure how this is possible tho | 15:00 |
| freemangordon | most-probably because there is some logic based on current | 15:00 |
| uvos | maybe | 15:00 |
| freemangordon | and your initial current maybe is too low | 15:00 |
| uvos | but why would sysfs then be correct | 15:00 |
| freemangordon | because later-on the cirrent is alredy high | 15:00 |
| tmlind | or we have cpcap charger driver handle the positive and negative current the wrong way around? | 15:00 |
| freemangordon | *curent | 15:00 |
| uvos | tmlind: no | 15:00 |
| freemangordon | *current | 15:01 |
| uvos | tmlind: pretty sure thats fine | 15:01 |
| uvos | freemangordon: but that dosent hold water | 15:01 |
| uvos | since if you load the device | 15:01 |
| uvos | sysfs dosent change | 15:01 |
| uvos | but its again discharging the battery | 15:01 |
| freemangordon | sure it does | 15:01 |
| uvos | (in real terms) | 15:01 |
| freemangordon | uvos: sec, lemme try to explain what I think happens: | 15:01 |
| uvos | pretty sure i tryed this | 15:01 |
| uvos | let me try again | 15:02 |
| freemangordon | when the initial event is send, charging current is below used cirrent | 15:02 |
| freemangordon | *current | 15:02 |
| freemangordon | so basically it is discharging | 15:02 |
| uvos | sure yeah | 15:03 |
| uvos | cat /sys/class/power_supply/battery/status | 15:03 |
| uvos | afaik | 15:03 |
| uvos | let me install stress | 15:03 |
| uvos | freemangordon: your right | 15:04 |
| freemangordon | for some reason no new event is send when charging current increases enough for charging to actually happen | 15:04 |
| uvos | stress -n 2 | 15:04 |
| uvos | causes sysfs to rappidly flip | 15:04 |
| uvos | back and fourth | 15:04 |
| freemangordon | mhm | 15:04 |
| uvos | ok | 15:04 |
| uvos | hmm | 15:04 |
| uvos | so just report on the battery state later then | 15:04 |
| uvos | (in the patch) | 15:04 |
| uvos | but the kernel is still bugy | 15:05 |
| uvos | if i enable charging | 15:05 |
| uvos | and then the kernel framework says "no current is positive" | 15:05 |
| uvos | it should report the battery as charging to udev | 15:05 |
| uvos | when curent is positive again | 15:05 |
| uvos | otherwise i cant guarentee the event is right at all | 15:05 |
| freemangordon | who triggers the event? | 15:06 |
| tmlind | the sysfs state for battery instead of usb should be used.. | 15:06 |
| uvos | tmlind: yes | 15:06 |
| freemangordon | tmlind: it is | 15:06 |
| uvos | this is for battery | 15:06 |
| tmlind | ok | 15:06 |
| uvos | freemangordon: so the real bug is | 15:06 |
| freemangordon | hmm? | 15:08 |
| uvos | the real bug the kernel dosent issue an event when it changes the state due to current sign changeing | 15:08 |
| uvos | it dose correctly issue an event when charging state changes | 15:09 |
| uvos | and the patch just makes this happen more often | 15:09 |
| freemangordon | uvos: but, is it correct that you say to the framework that it is charging, but current is negative? | 15:09 |
| freemangordon | I don't think this makes sense | 15:10 |
| uvos | yeah so the driver is charging in the sense of its internal state | 15:10 |
| freemangordon | ok, but it is not logical to charge with negative current :) | 15:10 |
| uvos | battery current should be negative | 15:10 |
| uvos | it makes perfect sense | 15:10 |
| freemangordon | no, it should be positive when cherging | 15:10 |
| uvos | no | 15:10 |
| uvos | battery is a device type power_supply | 15:11 |
| freemangordon | yeah, sorry | 15:11 |
| freemangordon | my bad | 15:11 |
| uvos | discharging => removeing energy => supplying energy => positive value | 15:11 |
| freemangordon | ok,ok | 15:11 |
| freemangordon | anyway, it is not logical then to enter charging state while still suplying energy | 15:11 |
| uvos | and it dosent | 15:11 |
| uvos | that is fine | 15:12 |
| uvos | just when it later dose enter charging state | 15:12 |
| freemangordon | I bet this is what happens | 15:12 |
| uvos | it is | 15:12 |
| uvos | it dosent issue another event | 15:12 |
| freemangordon | you report charging with *positive* current | 15:12 |
| uvos | no negative | 15:12 |
| uvos | look at what happens | 15:12 |
| uvos | watch -n 0.1 cat /sys/class/power_supply/battery/status | 15:12 |
| freemangordon | uvos: I understand what you say | 15:13 |
| freemangordon | you say that wonce current changes sign an even shall be send | 15:13 |
| uvos | watch -n 0.1 cat /sys/class/power_supply/battery/current_avg | 15:13 |
| freemangordon | right? | 15:13 |
| uvos | stress -c 2 | 15:13 |
| uvos | freemangordon: yes | 15:13 |
| freemangordon | ok, what I am saying is that this even is not send, because there is no change in the state | 15:14 |
| uvos | and cpcap-charger dosent do this at all (change state on sign) so it must be a framework thing | 15:14 |
| freemangordon | it is charging all the time | 15:14 |
| uvos | (or im not finding it) | 15:14 |
| freemangordon | you supply initial state as charging | 15:14 |
| uvos | right but the framework changes this to discharging | 15:14 |
| uvos | and then later back to charging | 15:14 |
| freemangordon | BTW does it poll? | 15:14 |
| uvos | and dosent send an event | 15:15 |
| uvos | freemangordon: no | 15:15 |
| freemangordon | how FW knows that current has changed its sign? | 15:15 |
| uvos | not the cpcap drivers themselves | 15:15 |
| uvos | idk how it works | 15:15 |
| freemangordon | it does not | 15:15 |
| freemangordon | driver shall signal somehow | 15:15 |
| uvos | i mean how the sign switching is detected | 15:15 |
| freemangordon | ok, lets think about it for a while: | 15:16 |
| uvos | cpcap_charger_irq_thread | 15:16 |
| freemangordon | we can sense that by either interrupt or polling, right? | 15:16 |
| uvos | put a printf there and se if it fires | 15:16 |
| uvos | when sign changes | 15:16 |
| freemangordon | how do I know when the sign chagnes? | 15:16 |
| uvos | it happens when you run stress -c 2 | 15:17 |
| uvos | at 500mah input current | 15:17 |
| freemangordon | ok | 15:17 |
| freemangordon | do you know irq no? | 15:17 |
| uvos | hmm? | 15:17 |
| uvos | do it in the delayed work of | 15:17 |
| uvos | *ofc | 15:18 |
| freemangordon | I'll jest check in /proc | 15:18 |
| freemangordon | *just | 15:18 |
| uvos | sure | 15:19 |
| uvos | never sure what irq is what there | 15:19 |
| freemangordon | uvos: watch -n 0.1 -d 'cat /proc/interrupts | grep cpcap' | 15:24 |
| freemangordon | no interrupt triggered | 15:24 |
| uvos | ok no idea then | 15:26 |
| uvos | sre should now, he is framework mantainer for power_suppy :P | 15:26 |
| uvos | and tmlind wrote the driver | 15:26 |
| freemangordon | ok, but I was seeing "device using more power" before that change | 15:27 |
| freemangordon | so it must have worked somehow | 15:27 |
| uvos | maybe the framework checks only when something touches the deivce | 15:28 |
| uvos | so the device using more power thing could only pop up when upower was reading sysfs | 15:28 |
| freemangordon | uvos: hmm https://github.com/maemo-leste/droid4-linux/commit/549645980ae302c6b13f62e29715420a08b87bb2#diff-ffffe39a400007faafb9049b0d20245c5a0ee6759068ce3e53d921f498f57318R670 | 15:29 |
| freemangordon | what is the idea? | 15:29 |
| freemangordon | "&& ddata->status != POWER_SUPPLY_STATUS_CHARGING" | 15:30 |
| freemangordon | is that possible? | 15:30 |
| freemangordon | also, why do you still schedule work after ichrg_current == ichrg ? | 15:31 |
| freemangordon | I would say you should stop, no? | 15:31 |
| freemangordon | unless I am missing the logic | 15:31 |
| freemangordon | ah, it returns early | 15:32 |
| uvos | it runs one step extra yeah | 15:33 |
| uvos | should probubly fix that | 15:33 |
| uvos | but dosent matter | 15:33 |
| uvos | (for this bug) | 15:33 |
| freemangordon | I think the issue is with "&& ddata->status != POWER_SUPPLY_STATUS_CHARGING" | 15:33 |
| freemangordon | why is that check needed at all? | 15:33 |
| uvos | because the current can change | 15:34 |
| uvos | so the user can set a different max current | 15:34 |
| uvos | we then continue ramping | 15:34 |
| uvos | but we where charging before | 15:34 |
| uvos | so dont set it again | 15:34 |
| uvos | so we have max current 300mA for instance | 15:34 |
| uvos | and usb gets pluged in | 15:34 |
| uvos | we ramp to 300 | 15:34 |
| uvos | and set the charging state | 15:34 |
| uvos | then user sets max current to 500mA | 15:35 |
| uvos | we continue ramping | 15:35 |
| uvos | but dont want to reset the state | 15:35 |
| uvos | (since it dident change) | 15:35 |
| uvos | thats the logic | 15:35 |
| freemangordon | ok, but are you sure https://github.com/maemo-leste/droid4-linux/commit/549645980ae302c6b13f62e29715420a08b87bb2#diff-ffffe39a400007faafb9049b0d20245c5a0ee6759068ce3e53d921f498f57318R671 is ever called? | 15:35 |
| uvos | yeah | 15:35 |
| uvos | not way sysfs can be correct otherwise | 15:35 |
| uvos | also from the logic jeah | 15:35 |
| freemangordon | sysfs is on-demand | 15:35 |
| uvos | right but it just reads that state | 15:36 |
| uvos | anyhow yeah it should | 15:36 |
| uvos | so | 15:36 |
| uvos | so ichrg_current < ichrg by 1 | 15:36 |
| freemangordon | yes, but this state could have been set earlier | 15:36 |
| uvos | then we ++ichrg_current | 15:36 |
| uvos | and then ichrg_current == ichrg | 15:36 |
| uvos | so yeah | 15:36 |
| freemangordon | before you start delayed work | 15:36 |
| uvos | should run | 15:36 |
| uvos | if the state is set erlier | 15:37 |
| uvos | either it was set to POWER_SUPPLY_STATUS_CHARGING | 15:37 |
| uvos | and we have nothing to do | 15:37 |
| freemangordon | my point | 15:37 |
| uvos | or its set to something else and POWER_SUPPLY_STATUS_CHARGING is set | 15:37 |
| uvos | freemangordon: so? | 15:37 |
| uvos | btw nothing else in the driver sets this state | 15:37 |
| freemangordon | that it is set to POWER_SUPPLY_STATUS_CHARGING earlier, but while the current was still too low, so FW reported discharging | 15:38 |
| uvos | fw dosent report anything | 15:38 |
| uvos | or framework | 15:38 |
| freemangordon | fw == framework | 15:38 |
| uvos | sure maybe thats what happens | 15:38 |
| uvos | but framweork then later changes the state back to POWER_SUPPLY_STATUS_CHARGING | 15:39 |
| uvos | as evidenced by sysfs | 15:39 |
| uvos | so it should report an event then | 15:39 |
| freemangordon | no, it just reads the current state | 15:39 |
| freemangordon | no | 15:39 |
| freemangordon | no, why event? | 15:39 |
| freemangordon | sysfs is just a representation of the state | 15:39 |
| freemangordon | nobody tracks if there is a chage | 15:40 |
| freemangordon | *change | 15:40 |
| freemangordon | it is driver that shall say "my state has changed" | 15:40 |
| uvos | sure | 15:40 |
| uvos | and it dose | 15:40 |
| uvos | if fw rejects this | 15:40 |
| uvos | it should tell the driver | 15:40 |
| uvos | or report later if the rejection changes | 15:40 |
| freemangordon | maybe it is a corner case not considered | 15:41 |
| uvos | otherwise how shal the driver know it has to report again | 15:41 |
| freemangordon | state == charging with current > 0 | 15:41 |
| uvos | but then it needs to poll | 15:41 |
| uvos | it cant do that | 15:41 |
| freemangordon | exactly | 15:41 |
| freemangordon | that's why the driver shall raise an event | 15:41 |
| uvos | it dose | 15:41 |
| freemangordon | I think it does not | 15:42 |
| uvos | when it enables charging | 15:42 |
| uvos | thats the only time it can | 15:42 |
| uvos | wihtout polling | 15:42 |
| freemangordon | yes, but it is too early then | 15:42 |
| uvos | yeah but | 15:42 |
| uvos | it might never be late enough | 15:42 |
| freemangordon | no, you have delayed work | 15:42 |
| uvos | how should the driver know | 15:42 |
| uvos | the current usage might simply be to high for the next 10 minutes | 15:42 |
| freemangordon | see, I don;t think you can report state == charging with positive current | 15:42 |
| freemangordon | that's my point | 15:42 |
| uvos | right | 15:42 |
| uvos | but if so | 15:43 |
| freemangordon | it does not make sense | 15:43 |
| uvos | i dont se how the driver can make it work | 15:43 |
| freemangordon | Pali: ping | 15:43 |
| Pali | pong | 15:43 |
| freemangordon | Pali: do you know, in theory, is it allowed/sane to report battery state as "charging" and "current now" saying that battery supplies energy? | 15:44 |
| uvos | freemangordon: https://github.com/maemo-leste/droid4-linux/blob/549645980ae302c6b13f62e29715420a08b87bb2/drivers/power/supply/cpcap-battery.c#L586 | 15:45 |
| uvos | here its that | 15:45 |
| uvos | not fw | 15:45 |
| Pali | IIRC negative current now is suppose to do | 15:45 |
| uvos | so udev gets an event that somthing changes | 15:45 |
| uvos | and reads it | 15:45 |
| uvos | and but cpcap-battery reports no | 15:45 |
| uvos | so the fix is to check with cpcap-charger what it thinks should be happening | 15:46 |
| uvos | not the "real" state | 15:46 |
| uvos | otherwise it cant work | 15:46 |
| uvos | without polling | 15:46 |
| uvos | it probubly fails for you because your usb cable is high inductiviy or something | 15:47 |
| freemangordon | uvos: so, at the moment udev receives "charging" event, "current now" is still announcing "discharging" | 15:47 |
| uvos | yes | 15:47 |
| uvos | beacuse cpcap-battery reports | 15:47 |
| uvos | in the line linked above | 15:47 |
| uvos | not current now directly | 15:47 |
| freemangordon | come on, the cable is perfect | 15:48 |
| uvos | but battery state sysfs file | 15:48 |
| uvos | freemangordon: sure its fine but it dosent happen here | 15:48 |
| freemangordon | actually thi is my best cable | 15:48 |
| uvos | freemangordon: so the differens is electrical most likely | 15:48 |
| uvos | anyhow | 15:48 |
| freemangordon | uvos: and? because it works for you that means we can leave it like that or what? | 15:48 |
| uvos | no | 15:48 |
| uvos | wtf | 15:48 |
| uvos | anyhow cpcap-charge must allways report charging in state sysfs file (not in current that dosent mattter) when cpcap-charger has enabled charging | 15:49 |
| uvos | anyhow cpcap-battery must allways report charging in state sysfs file (not in current that dosent mattter) when cpcap-charger has enabled charging | 15:49 |
| freemangordon | ok, so, how is "current too high" detected? | 15:50 |
| freemangordon | I guess someone polls | 15:50 |
| uvos | yeah | 15:50 |
| freemangordon | ok, that's fine | 15:50 |
| freemangordon | ok, so, do you want me to put printks somewhere? | 15:51 |
| uvos | no its fine | 15:51 |
| uvos | we know why it happens | 15:51 |
| freemangordon | umm, lemme read it again, as I am not sure I know | 15:51 |
| uvos | unfortionatly having the state sysfs file follow current (ie real charging vs discharing) state is impossible without polling in kernel | 15:52 |
| uvos | without breaking events | 15:52 |
| uvos | so we have to make it show intended state not real state | 15:52 |
| freemangordon | that's fine I guess, as this polling happens only when charger is connected | 15:52 |
| uvos | no | 15:53 |
| uvos | you would have to poll also while discharging and connected | 15:53 |
| uvos | i dont think thats fine | 15:53 |
| freemangordon | uvos: so, "charging" here means "charging connected", right? | 15:53 |
| uvos | at all | 15:53 |
| uvos | yes so charging in the sense that the charging registers are enabled | 15:53 |
| uvos | this is different from connected | 15:53 |
| uvos | and from current state | 15:53 |
| freemangordon | ok, I still fail to understand why it does not work then. | 15:54 |
| freemangordon | uvos: also, lets forget about sysfs | 15:54 |
| freemangordon | it is not related to events | 15:54 |
| uvos | it is | 15:54 |
| freemangordon | how's that? | 15:54 |
| uvos | udev gets a changed event | 15:54 |
| freemangordon | and reads sysfs? | 15:55 |
| uvos | and then reads sysfs to get what it changed to | 15:55 |
| uvos | iiuc | 15:55 |
| freemangordon | I think event itself contains the change | 15:55 |
| freemangordon | but not sure | 15:55 |
| freemangordon | I guess I can strace | 15:55 |
| Wizzup | udev listens on netlink which probably already contains some info, but they are closely linked | 15:55 |
| freemangordon | Wizzup: the point is that information comes with the event | 15:55 |
| freemangordon | you don;t just receive "something changed" | 15:56 |
| freemangordon | no? | 15:56 |
| Wizzup | yes, over netlink | 15:56 |
| freemangordon | exactly | 15:56 |
| Wizzup | I would assume kernel makes drivers able to change both sysfs and netlink events at once though, so they should be linked | 15:56 |
| uvos | freemangordon: just change https://github.com/maemo-leste/droid4-linux/blob/549645980ae302c6b13f62e29715420a08b87bb2/drivers/power/supply/cpcap-battery.c#L586 | 15:57 |
| uvos | to read the charging register instead | 15:57 |
| uvos | of the current | 15:57 |
| uvos | eveything will work fine | 15:57 |
| uvos | then | 15:57 |
| uvos | im allmost certain | 15:57 |
| freemangordon | and because the initial event comes at the very beginning, either state is still "discharging" (as we are about to ramp-up) or the current is not ok | 15:57 |
| uvos | no | 15:57 |
| uvos | it comes at the end | 15:57 |
| freemangordon | uvos: where from? | 15:58 |
| uvos | its reported at the end by cpcap-charger | 15:58 |
| uvos | in the delayed work funciton | 15:58 |
| freemangordon | end of ramp-up? | 15:58 |
| uvos | i made sure to change the state at the end of ramp-up | 15:58 |
| uvos | but ofc | 15:58 |
| freemangordon | hmm | 15:58 |
| uvos | current might still be negative | 15:58 |
| uvos | since its an avg | 15:58 |
| uvos | over some length | 15:58 |
| freemangordon | ok, lemme see what is reported | 15:58 |
| freemangordon | uvos: ah, I see | 16:00 |
| freemangordon | uvos: isn't it better to delay status report? | 16:00 |
| uvos | no | 16:00 |
| uvos | beacuse what happens if the device is loaded | 16:00 |
| uvos | you dont know how long oyu need to delay | 16:01 |
| freemangordon | right | 16:01 |
| freemangordon | but, how you want me to change that? | 16:01 |
| freemangordon | if (cpcap_battery_cc_get_avg_current(ddata) < 0) I mean | 16:01 |
| freemangordon | this makes sense | 16:01 |
| uvos | just report the state of CPCAP_REG_CRM instead of current in POWER_SUPPLY_PROP_STATUS | 16:02 |
| uvos | current sure makes sense | 16:02 |
| uvos | but we cant make it work | 16:02 |
| uvos | i dont see how | 16:02 |
| freemangordon | ok, lemme think about this for a while | 16:03 |
| freemangordon | uvos: that's how: on ichrg_current == ichrg, schedule HZ/10 delayed work and report POWER_SUPPLY_STATUS_CHARGING on that scheduled work | 16:11 |
| freemangordon | that way avg will have time to settle | 16:12 |
| freemangordon | ofc if you have 2 cores spinning 100%, udev will see discharging, but not much we can do | 16:13 |
| freemangordon | shall I do that patch and test it here? | 16:14 |
| uvos | no | 16:16 |
| uvos | thats terrible | 16:16 |
| uvos | so what happens if right at 10 sec theres a usage spike? | 16:16 |
| uvos | of current | 16:16 |
| uvos | er 1/10 second | 16:17 |
| uvos | also what happens if the user just enables charging with 200mA or whatever | 16:17 |
| uvos | you have to just report the state of CPCAP_REG_CRM instead of current in POWER_SUPPLY_PROP_STATUS | 16:17 |
| uvos | please also check what other drivers so | 16:18 |
| uvos | *do | 16:18 |
| uvos | n900 | 16:18 |
| uvos | acpi | 16:18 |
| freemangordon | uvos: sorry, don;t get it | 16:23 |
| freemangordon | you only changed how charge current is applied - immediately vs ramp, right? | 16:24 |
| uvos | yes | 16:24 |
| freemangordon | so, what I propose will fix the issue caused by that chagne | 16:25 |
| freemangordon | if there is some general issue with status reporting, that's another story | 16:25 |
| freemangordon | and we shall report on ML | 16:25 |
| uvos | it was wrong before to | 16:25 |
| uvos | it just happend to work | 16:25 |
| freemangordon | exactly | 16:25 |
| uvos | but if you report the state of CPCAP_REG_CRM instead of current in POWER_SUPPLY_PROP_STATUS | 16:26 |
| freemangordon | but this driver has a maintainer, no? | 16:26 |
| uvos | its fixed | 16:26 |
| uvos | tmlind: | 16:26 |
| uvos | and me | 16:26 |
| uvos | really | 16:26 |
| freemangordon | what is CPCAP_REG_CRM? | 16:26 |
| uvos | target current | 16:26 |
| freemangordon | will we have "using too much power" notifications? | 16:26 |
| uvos | i dont know, depends on if it checks status or current | 16:27 |
| freemangordon | because this was definitely working | 16:27 |
| freemangordon | and I am afraid we will break it | 16:27 |
| uvos | yeah but you cant have status reflect real current | 16:27 |
| uvos | and not have the event be a random number generator | 16:28 |
| uvos | its impossible | 16:28 |
| uvos | unless you poll | 16:28 |
| freemangordon | also, I think we have this 500 mA limit issue as well. if our budget is 1.5A then we won;t have those problems I guess | 16:29 |
| uvos | thats just hiding it | 16:29 |
| uvos | also you can acivate 1.5a | 16:30 |
| uvos | i do | 16:30 |
| uvos | its just not safe to do generally | 16:30 |
| freemangordon | mhm | 16:30 |
| uvos | besides its still a problem with 1.5a | 16:31 |
| uvos | gues who plugs in there phone with sgx and cpu fully loaded | 16:31 |
| uvos | ? | 16:31 |
| uvos | absolutly everyone who plays games on mobile devices | 16:31 |
| freemangordon | yeah | 16:31 |
| uvos | even 1.5a is not enough | 16:31 |
| freemangordon | lemme check what n900 driver does | 16:32 |
| freemangordon | uvos: oh, wait :) | 16:34 |
| freemangordon | see https://elixir.bootlin.com/linux/latest/source/include/linux/power_supply.h#L38 | 16:34 |
| uvos | i dont se how that helps us | 16:35 |
| uvos | we cant switch to and away from that without polling | 16:35 |
| freemangordon | uvos: still, POWER_SUPPLY_STATUS_NOT_CHARGING is the correct status to report if charger is connected but it cannot supply enough current, no? | 16:36 |
| uvos | yes | 16:37 |
| uvos | but we cant do that | 16:37 |
| freemangordon | why? | 16:37 |
| uvos | since we dont have irq to tell us when real current passes 0 | 16:37 |
| freemangordon | are you sure? | 16:37 |
| freemangordon | as this does not make sense | 16:38 |
| freemangordon | maybe it is not enabled | 16:38 |
| uvos | well the chip isent documented | 16:38 |
| freemangordon | I guess we dont; have docs | 16:38 |
| uvos | if so moto dosent use it | 16:38 |
| freemangordon | OTOH I don;t see any problem to poll when on charger | 16:39 |
| uvos | not sure how that interacts with inductive charging | 16:40 |
| freemangordon | https://github.com/maemo-leste/droid4-linux/blob/master/drivers/power/supply/bq27xxx_battery.c#L903 | 16:42 |
| freemangordon | uvos: what is chrgcurr1 irq? | 16:46 |
| sicelo | tmlind: nice @ wlroots. I must try sway again on my n900 | 16:48 |
| sicelo | You guys are busy and I don't want to interrupt, but I was going to ask where/how to see the charge mode in action, as I haven't seen it yet | 16:49 |
| uvos | should work on mapphones | 16:52 |
| uvos | in devel | 16:52 |
| sicelo | How? | 16:52 |
| uvos | if you boot with usb pluged in | 16:52 |
| sicelo | I'm testing on a mapphone | 16:53 |
| uvos | have the device off | 16:53 |
| uvos | plug in a usb cable | 16:53 |
| uvos | should be sufficant | 16:53 |
| sicelo | Mine boots leste | 16:53 |
| uvos | check if you charge-mode in cmdline | 16:53 |
| uvos | but should be in devel | 16:53 |
| uvos | but if you changed boot.cfg it wont update | 16:54 |
| sicelo | I'm always in -devel | 16:54 |
| uvos | so whats you cmdline? | 16:55 |
| sicelo | It's rebooting. Will see when it's back up | 16:55 |
| sicelo | Mmm, bootloop, heh | 16:56 |
| sicelo | Okay now looks like my new battery is broken :'( | 17:03 |
| sicelo | Maybe I'm hitting the same issue fmg is ... no idea. | 17:03 |
| * sicelo gets his power back ... the d4 usually seems happier with it | 17:04 | |
| sicelo | *bank | 17:08 |
| sicelo | No luck with this too. Back to Android charging. At least that works, so yeah ... appears I'm facing what issue fmg faces | 17:09 |
| uvos | right | 17:09 |
| uvos | its one and the same issue | 17:09 |
| uvos | the device will shutdown if it enters hildon with the battery to low but it should never get there | 17:09 |
| uvos | it should stay in charge mode | 17:09 |
| uvos | so for some reason yours isent | 17:09 |
| uvos | probubly because you at some point touched boot.cfg | 17:10 |
| uvos | and leste config wont update it if it was touched | 17:10 |
| sicelo | I haven't. No reason to | 17:11 |
| uvos | maybe hildon-meta is not installed? | 17:12 |
| uvos | there was a packaginge problem where apt uninstalled it during upgrade some time ago | 17:12 |
| uvos | if so then charge-mode simply isent installed | 17:12 |
| sicelo | I think I have it (meta). Anyway, can't tell right now | 17:13 |
| rafael2k | I pulled the upstream changes of pine64-kernel to my fork | 17:17 |
| rafael2k | btw, how do you compile the kernel? | 17:19 |
| Wizzup | rafael2k: is that aimed at me? | 17:21 |
| Wizzup | rafael2k: what is 'upstream' here? | 17:21 |
| Wizzup | do you mean the maemo/beowulf-devel branch? | 17:21 |
| rafael2k | yes! | 17:22 |
| Wizzup | the kernel is built on the CI using git build package | 17:23 |
| Wizzup | if you want to mimic it locally then checkout the maemo-kernel-5.15 tag (or the maemo mobian-5.15 branch) and then run 'git checkout maemo/beowulf-devel debian' from it and then 'dpkg-buildpackage -b -uc' | 17:23 |
| Wizzup | (from memory) | 17:23 |
| Wizzup | I'm going to the supermarket for a bit | 17:24 |
| sicelo | Charge mode installed, softlevel=charge exists in boot.cfg | 17:37 |
| sicelo | Anyway, charging doesn't work at all for me now. | 17:39 |
| uvos | thats wrong | 17:42 |
| uvos | should be charge-mode or charge_mode | 17:43 |
| uvos | dont quite remember what i named it | 17:43 |
| sicelo | Anyone ever tested n900's IR with mainline? It probes perfectly well, and the proprties of the device can be fetched. Trying to send an IR pulse makes kernel hang instantly however | 18:06 |
| uvos | not me | 18:06 |
| uvos | but its just a gipo right? cant be so hard to fix it | 18:06 |
| sicelo | I'll maybe test it further in the near future but if someone has, would be nice to hear | 18:07 |
| freemangordon | uvos: obviously both me and sicelo are facing exactly the same behaviour | 19:14 |
| freemangordon | I think it makes sense to revert that patch (or those patches) as of now, to be able to push -devel to -stable after some quarantine period | 19:15 |
| Wizzup | we can do that, but if we can find a fix that works too | 19:18 |
| freemangordon | I proposed one that will fix the behaviour to the state before patch, but uvos didn;t like it | 19:27 |
| Wizzup | I thought he had a fix | 19:27 |
| freemangordon | I don;t hink it is a proper one | 19:27 |
| Wizzup | but I didn't follow along | 19:27 |
| freemangordon | please read the backscroll, maybe I didn't understand it | 19:28 |
| freemangordon | brb | 19:28 |
| Wizzup | freemangordon: around 16:57 your time | 19:43 |
| freemangordon | mhm | 19:43 |
| freemangordon | but, this is a change in the behaviour | 19:43 |
| freemangordon | which needs testing as well. that's why I think it is better to revert, push to -stable and then try to fix whatever needs to be fixed | 19:44 |
| Wizzup | sure we can do that | 19:44 |
| Wizzup | it did make charging much more stable for me though, but we see it is better in some ways only | 19:45 |
| freemangordon | I am not saying the patch is bad or not needed, it is just that it needs more polishing | 19:45 |
| freemangordon | I prefer to be done after -stable release | 19:45 |
| uvos | the issue is independant of the patch really | 19:45 |
| uvos | anyhow just having the state report what target current fixes all reall issues | 19:46 |
| uvos | and thats a small easy one liner | 19:46 |
| uvos | we can talk about polling | 19:46 |
| uvos | or finding an irq later | 19:46 |
| freemangordon | the patch I proposed makes more sense to me, as it restores the behaviour as it has been before the ramp-up patch | 19:47 |
| uvos | but it dosent solve the issue | 19:47 |
| freemangordon | sure, but it is *another* issue | 19:47 |
| uvos | just because in your setup the electrical timeing hapens to line up like that | 19:47 |
| uvos | means nothing really | 19:47 |
| uvos | no its the same issue | 19:47 |
| uvos | just my patch alters timeing a bit | 19:47 |
| uvos | so this starts happening to you | 19:47 |
| freemangordon | uvos: just because it works for you means nothing, really | 19:47 |
| uvos | and sicleo too | 19:47 |
| uvos | if i change it to report target current | 19:48 |
| uvos | it will work for everbody | 19:48 |
| uvos | no matter what iductivity/regulation charecaristicts the usb wall wart hast | 19:48 |
| freemangordon | and it will report the real state incorrectly | 19:48 |
| uvos | *has | 19:48 |
| uvos | sure but we can investigate how to fix that latter | 19:49 |
| uvos | this patch exits because charging dident work for ME | 19:49 |
| freemangordon | current reporting is correct | 19:49 |
| freemangordon | *currently | 19:49 |
| uvos | except with one signle usb cable i have | 19:49 |
| uvos | well tough | 19:49 |
| uvos | we cant make it report correctly and not have the timeing issue | 19:49 |
| uvos | without polling | 19:49 |
| freemangordon | uvos: that's why I proposed to extend it to report the state after _avg has settlet | 19:49 |
| freemangordon | I know | 19:49 |
| uvos | or figureing more out about the chip | 19:49 |
| freemangordon | agree | 19:50 |
| uvos | so lets just fake it untill we know how to fix it for real | 19:50 |
| freemangordon | why? instead of delaying the initial state reporting for 100ms? | 19:50 |
| freemangordon | you may as well hardcode | 19:50 |
| uvos | thats terrible | 19:51 |
| uvos | sorry | 19:51 |
| uvos | it dosent solve the issue at all | 19:51 |
| freemangordon | I am not saying my proposal fixed the issue | 19:51 |
| uvos | just makes it maybe slightly less common | 19:51 |
| freemangordon | it will just make it like before ramp-up patch | 19:51 |
| uvos | right and it dident work before the ram up patch | 19:52 |
| uvos | just on different configurations | 19:52 |
| freemangordon | right, I am not saying to revert ramp-up patch, but to extend it | 19:52 |
| uvos | can you just let me fix my own damn patch | 19:52 |
| uvos | yeez | 19:52 |
| freemangordon | sure, after a -stable release | 19:52 |
| Wizzup | we do not need a -stable right now, I was just asking | 19:57 |
| Wizzup | if there is a fix that makes it work for us all we can wait a bit | 19:57 |
| Wizzup | no rush | 19:57 |
| freemangordon | and what about "charge-mode"? | 19:58 |
| uvos | what about it | 19:58 |
| freemangordon | it doesn;t work here either | 19:58 |
| freemangordon | and I didn;t play woth boot.cfg or whatever | 19:59 |
| freemangordon | *with | 19:59 |
| uvos | probubly one and the same issue | 19:59 |
| Wizzup | yeah I think so | 19:59 |
| Wizzup | it works for me | 19:59 |
| uvos | i dont quite remember how i had charge-mode detect if the device is charging | 19:59 |
| Wizzup | (charge mode) | 19:59 |
| uvos | but maybe i used status | 19:59 |
| freemangordon | maybe the same issue, yeah | 19:59 |
| Wizzup | but I ended up on the right side of this patch :) | 19:59 |
| Wizzup | it sounds like sicelo can maybe help test a new patch as well | 20:00 |
| Wizzup | uvos: so what do you think, should I exclude those charging patches from a new kernel build and then look at moving it all to stable, and then include those patches with a fix? I am not in a rush, just trying to get a sense what would work best for you :-) | 20:07 |
| freemangordon | tmlind: I am sure I checked that extension is not announced, lemme see what's going on | 20:25 |
| tmlind | freemangordon: ok | 20:29 |
| tmlind | trying to figure out why my es2gears_wayland stopped working.. | 20:29 |
| tmlind | i think that happened already a while back, need to grep the irc.txt | 20:29 |
| freemangordon | uh: the check if for dri2_dpy->image->base.version >= 8 | 20:34 |
| freemangordon | *is for | 20:34 |
| inky | uvos, i maybe forgot what was the problem with the keyboard, i remember i generated u a header file, but | 20:35 |
| inky | do we need it? | 20:35 |
| inky | if the maemo user chooses | 20:35 |
| inky | a, yes we needed that | 20:36 |
| inky | but the other problem now is that | 20:36 |
| inky | you don't know which language is being typed to execute setxkbmap | 20:36 |
| inky | but we know! | 20:36 |
| inky | because if i choose armenian layout then as i have chosen it | 20:36 |
| inky | setxkbmap am | 20:37 |
| inky | should be issued | 20:37 |
| inky | by vkbd | 20:37 |
| inky | otherwise i do two things | 20:37 |
| inky | i choose armenian, then in terminal type setxkbmap am | 20:37 |
| freemangordon | tmlind: yeah, my bad | 20:37 |
| inky | it can be done automaticlly | 20:37 |
| freemangordon | this has to be 8, not 14 | 20:37 |
| inky | uvos, do you want we to give u a table of setxkbmap layouts that correspond to languages we hve in vkbd? | 20:38 |
| freemangordon | hmm, 8 should support modifiers too | 20:38 |
| freemangordon | tmlind: so, according to mesa, if you support EXT_image_dma_buf_import you must support EXT_image_dma_buf_import_modifiers too | 20:39 |
| freemangordon | tmlind: but still, could you change https://github.com/maemo-leste-upstream-forks/mesa/blob/maemo/beowulf-devel/src/mesa/drivers/dri/pvr/pvrext.c#L78 from 14 to 8 and try with that change? | 20:41 |
| freemangordon | tmlind: or, shall I build on the device? | 20:46 |
| Wizzup | inky: just wondering, does the h-i-m method of changing keymaps work for you | 20:46 |
| Wizzup | I don't think I got it to switch languages | 20:46 |
| tmlind | freemangordon: ok i'll try just a few mins | 20:46 |
| freemangordon | thanks! | 20:46 |
| tmlind | only 11 files to build.. | 20:48 |
| tmlind | well 11 steps actually with linking | 20:48 |
| freemangordon | well, thats great | 20:49 |
| tmlind | freemangordon: yup, changing it to 8 fixes the issue | 20:50 |
| freemangordon | :) | 20:50 |
| tmlind | oh looks like install did not happen | 20:51 |
| tmlind | ERROR: Build directory has been generated with Meson version 0.60.2, which is incompatible with the current version 0.61.0. | 20:51 |
| tmlind | heh let's see if it will be a full rebuild :) | 20:51 |
| tmlind | phew only 38 steps, not a full rebuild after meson --reconfigure build | 20:54 |
| _inky | Wizzup: you mean with hildon programs? | 20:54 |
| _inky | or with X programs? | 20:54 |
| uvos | _inky: i yeah i know this is still a problem | 20:56 |
| uvos | _inky: its not a priority for me atm, sorry | 20:56 |
| uvos | _inky: so i dont want a table | 20:56 |
| _inky | uvos, i think we even know the names of the mappings. | 20:56 |
| _inky | yes, okay. | 20:56 |
| _inky | i mean the source code already contains the names. | 20:56 |
| uvos | _inky: i think it would be better if the vkb could just pick a couple of safe keycodes to overwrite | 20:57 |
| uvos | _inky: and then change the keymap on the fly | 20:57 |
| _inky | i mean, no need to take keycodes even | 20:57 |
| uvos | by modifing it with the keys it needs to send the string | 20:57 |
| uvos | and then restoring the keyboard map | 20:57 |
| _inky | i choose the layout explicitly | 20:57 |
| _inky | to type | 20:57 |
| tmlind | freemangordon: still getting wlroots error [wlr] [render/egl.c:765] Failed to query number of dmabuf formats | 20:58 |
| uvos | sure but the hwkybd also needs to wrok at the same time | 20:58 |
| _inky | it is in the source as hy_AM - then setxkbmap am should be executed. | 20:58 |
| uvos | so the way to make that happen is take the string the user wants the vkb to send to the applicaiton "abced" | 20:58 |
| _inky | if i choose russian, then it's ru_RU in our source, then setxkbmap will cover all the chars. | 20:58 |
| uvos | add abced to the keymap | 20:58 |
| uvos | send string | 20:58 |
| uvos | restore keymap | 20:58 |
| freemangordon | tmlind: ok, I think this is a bug in mesa then | 20:58 |
| _inky | i just had the idea that it could be much much easier. | 20:59 |
| _inky | because the user explicitly chooses the layout before typing | 20:59 |
| uvos | yeah but ru_RU dosent cover all the chars | 20:59 |
| uvos | is the problem | 20:59 |
| _inky | i choose the layout, then we know which setxkbmap needs to be executed | 20:59 |
| uvos | not even en_US covers all the chars | 20:59 |
| uvos | on droid 4 with english vkb and english hwkbd | 21:00 |
| uvos | becaus vkb has lots of spcial chars | 21:00 |
| freemangordon | tmlind: I will need some more time to see what can be done | 21:00 |
| _inky | what kind of chars, i don't know about it. | 21:00 |
| uvos | some on the second page | 21:00 |
| _inky | Wizzup: yes, with maemo apps maemo kbd works without forcing me to do setxkbmap manually. | 21:00 |
| uvos | like the pound symbol i think | 21:00 |
| uvos | some others | 21:00 |
| _inky | but with regular debian apps not. | 21:00 |
| freemangordon | tmlind: maybe it is a good idea to ask someone that knows more then me though | 21:01 |
| tmlind | freemangordon: it checks for >= 8 :) i'll try 7 | 21:01 |
| _inky | i think it is much better for user now if the vkbd just execute setxkbmap according to the current layout, and the pound symbol not work, than scare the user away by telling them to execute setxkbmap each time. | 21:02 |
| uvos | and ru vkb with ru_RU keymap on droid 4 is entriely hopeless ofc | 21:02 |
| freemangordon | yeah, but then there will be no EXT_image_dma_buf_import as well | 21:02 |
| _inky | why hopeless? | 21:02 |
| tmlind | freemangordon: ah | 21:02 |
| uvos | becasue of all of the wrongly mapped keys | 21:02 |
| _inky | you mean hw kbd? i am very concerted with vkbd | 21:02 |
| _inky | also i don't have hwkbd on pinephone. | 21:02 |
| uvos | sure but you cant break the hwkbd to make the vkb work :P | 21:03 |
| _inky | eh. | 21:03 |
| uvos | anyhow as stated there is a solution | 21:03 |
| uvos | you have to have him modify the keymap on the fly | 21:03 |
| uvos | but its not a priority for me atm, sorry | 21:04 |
| uvos | maybe some one else wants to pick it up | 21:04 |
| uvos | Wizzup: just wait, ill give you a temp fix tomorow | 21:10 |
| uvos | and then we can discuss a proper fix at some later point | 21:10 |
| freemangordon | tmlind: how exactly does it fail? | 21:12 |
| freemangordon | because IIRC it was segfaulting before, no? | 21:13 |
| freemangordon | ah, "Failed to query number of dmabuf formats" | 21:13 |
| freemangordon | but, it should check for the extension first | 21:13 |
| freemangordon | tmlind: see dri2_query_dma_buf_formats | 21:16 |
| freemangordon | hmm, well, I think this is really bug in mesa | 21:18 |
| tmlind | freemangordon: i think we can disable it in the pvr driver but i need to look at that stuff more | 21:18 |
| freemangordon | I'd rather will fix mesa to check for proper image version | 21:19 |
| tmlind | freemangordon: fyi, see the wlroots logic here at https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/render/egl.c#L258 | 21:22 |
| freemangordon | wait, what the? | 21:23 |
| freemangordon | sec | 21:23 |
| freemangordon | tmlind: look at https://github.com/anholt/mesa/blob/master/src/egl/drivers/dri2/egl_dri2.c#L737 | 21:23 |
| tmlind | freemangordon: and see also the wlroots fallback logic we can use at https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/render/egl.c#L745 | 21:23 |
| freemangordon | why we don;t have that code? | 21:24 |
| freemangordon | tmlind: we have some issue with our mesa | 21:24 |
| freemangordon | see the link ^^^ | 21:24 |
| tmlind | freemangordon: ah maybe we need to backport some patch? | 21:25 |
| freemangordon | no, this is 5yo | 21:25 |
| freemangordon | https://github.com/anholt/mesa/commit/4c412293d0e3e38f6b4e9c10b492b8ed1d9a4a69 | 21:25 |
| freemangordon | May 30, 2017 | 21:26 |
| freemangordon | WTF?!? | 21:26 |
| freemangordon | ok, seems this was initially broken :( | 21:27 |
| freemangordon | so, we're using wring version of this file | 21:28 |
| freemangordon | hmm this check was dropped for some reason, lemme try to find the commit | 21:29 |
| freemangordon | this: https://github.com/maemo-leste-upstream-forks/mesa/commit/4e3a7dcf6ee4946c46ae8b35e7883a49859ef6fb#diff-1068a0daaafeee588896c915b1377ef8438fdb813a09602d1c88e92916a6ea22 | 21:29 |
| tmlind | seems that stuff is super buggy.. | 21:33 |
| freemangordon | tmlind: yeah | 21:33 |
| tmlind | on the hardware i mean | 21:33 |
| freemangordon | for sure we shall advertise version 8, not 14 | 21:33 |
| tmlind | probably best to just disable it for pvr driver rather than try to get tangled for fixing it for whatever pc quirks | 21:34 |
| freemangordon | it is not about pvr driver only | 21:34 |
| freemangordon | we use same mesa on all devices | 21:34 |
| tmlind | right and they will have these calls implemented | 21:35 |
| tmlind | my guess is that later versions of sgx also work fine | 21:35 |
| freemangordon | tmlind: I think the issue is with get_egl_dmabuf_formats in wlroots | 21:35 |
| tmlind | freemangordon: same story there.. trying to mess with it breaks something else likely :) | 21:36 |
| freemangordon | because, note in that mesa commit is that the call may return zero formats | 21:36 |
| tmlind | right but wlroots does not assume the call will fail like it does for pvr blobs | 21:37 |
| freemangordon | but it fails in mesa, not in pvr | 21:37 |
| tmlind | hmm | 21:37 |
| freemangordon | because pvr properly announces that it does not support that | 21:37 |
| tmlind | no, we advertise those two extensions | 21:38 |
| tmlind | but they will fail because they're not implemented | 21:38 |
| freemangordon | no, mesa does | 21:38 |
| tmlind | where? | 21:38 |
| freemangordon | and actually the first one ( p, li { white-space: pre-wrap; } EXT_image_dma_buf_import) is implemented | 21:38 |
| freemangordon | sec | 21:39 |
| tmlind | right, EXT_image_dma_buf_import and works | 21:39 |
| tmlind | modifiers are not implemented, you removed those with your patch earlier | 21:39 |
| freemangordon | https://github.com/maemo-leste-upstream-forks/mesa/blob/maemo/beowulf-devel/src/egl/drivers/dri2/egl_dri2.c#L2754 | 21:40 |
| freemangordon | they were never implemented | 21:40 |
| freemangordon | that was a remnant from chromeos version | 21:40 |
| freemangordon | and it was segfaulting because chromeos was announcing version 15 or 17 | 21:41 |
| freemangordon | yeah, 17 | 21:42 |
| tmlind | so the chromeos version had PVRDRIQueryDmaBufModifiers etc | 21:42 |
| freemangordon | yes | 21:42 |
| freemangordon | but no :) | 21:42 |
| tmlind | are you saying there should be now generic handling for the modifiers? | 21:42 |
| uvos | froububly yes for series 6 | 21:42 |
| freemangordon | because it dloads pvr_dri_support.so blob | 21:42 |
| uvos | *probubly | 21:42 |
| freemangordon | and our blob does not supports thoes | 21:42 |
| uvos | right | 21:43 |
| freemangordon | maybe series 6 blob supports it | 21:43 |
| tmlind | yeah ok that's what i though | 21:43 |
| freemangordon | that's why I removed everything that is not supported | 21:43 |
| freemangordon | and actually pvr_dri (blob) announces version 8 | 21:43 |
| tmlind | sure, but we still advertise the the modifiers :) | 21:43 |
| freemangordon | no, we don't | 21:43 |
| freemangordon | it is mesa that does unconditionally | 21:44 |
| freemangordon | look at the patch | 21:44 |
| freemangordon | https://github.com/maemo-leste-upstream-forks/mesa/commit/4e3a7dcf6ee4946c46ae8b35e7883a49859ef6fb#diff-1068a0daaafeee588896c915b1377ef8438fdb813a09602d1c88e92916a6ea22 | 21:44 |
| freemangordon | there was a check for dri_image version >= 15 | 21:44 |
| freemangordon | and we report 14 now (which is wrong, but still not 15) | 21:44 |
| freemangordon | "With this change, queryDmaBufModifiers always returns zero modifiers." | 21:45 |
| freemangordon | actually it does not, for some reason | 21:46 |
| freemangordon | but rather returns FALSE | 21:46 |
| tmlind | probably more quirk handling | 21:47 |
| freemangordon | yeah, the reason is that our version is < 15 | 21:47 |
| tmlind | hmm so should it be 15 then? | 21:47 |
| freemangordon | no because we don;t support that | 21:48 |
| freemangordon | it is 'our' dri driver that shall implement that and return sane values | 21:48 |
| freemangordon | but that function is not implemented in the blob | 21:48 |
| tmlind | so let's add back that dropped snippet? | 21:49 |
| freemangordon | :) | 21:49 |
| freemangordon | no, because we use the same mesa on PP, for example | 21:49 |
| freemangordon | ah, you mean the version? | 21:49 |
| tmlind | right the version check | 21:49 |
| freemangordon | yeah, maybe | 21:49 |
| freemangordon | but, I wonder if we shall raise an issue on mesa | 21:50 |
| tmlind | let me test adding the if (dri2_dpy->image->base.version >= 15... check back | 21:50 |
| freemangordon | ok | 21:50 |
| freemangordon | it seems they fixed only some of the code paths back then | 21:50 |
| freemangordon | tmlind: seems they fixed gallium dri2 frontend | 21:53 |
| tmlind | heh | 21:53 |
| tmlind | the version check for 15 was probably dropped for some old pc hardware | 21:54 |
| freemangordon | see dri2_query_dma_buf_modifiers in dri2 gallium frontend | 21:54 |
| uvos | well idk if upsream will be helpfull then | 21:54 |
| uvos | they just droped eveything except gallium 3d drivers | 21:54 |
| freemangordon | I think we shall patch egl_dri2.c to return zero modifiers instead of EGL_FALSE | 21:55 |
| tmlind | hehehe good luck merging that upstream :) | 21:55 |
| freemangordon | hmm? why? | 21:55 |
| tmlind | probably something somewhere breaks again | 21:56 |
| tmlind | but sure go for it if you have a proper fix in mind | 21:56 |
| tmlind | freemangordon: adding back the 15 check makes things work, but who knows what other things it might break.. | 21:57 |
| freemangordon | hmm, wait, they say that 'formats' query shall be always suppoerted, no? | 21:57 |
| tmlind | sounds like they pulled back | 21:57 |
| freemangordon | "This allows users to use queryDmaBufFormats..." | 21:58 |
| freemangordon | ok, this is really a mess | 21:59 |
| tmlind | but we don't have the function implemented at all, it's null | 21:59 |
| freemangordon | yes, we don't | 21:59 |
| freemangordon | we don;t support that | 22:00 |
| freemangordon | I would say this is strictly against specs | 22:00 |
| freemangordon | but... | 22:01 |
| freemangordon | or, we can implement queryDmaBufFormats to return zero formats | 22:02 |
| tmlind | that won't help, see the wlroots links i pasted earlier | 22:02 |
| tmlind | we either need to implement them in a way that works, or just have !egl->exts.EXT_image_dma_buf_import_modifiers | 22:03 |
| freemangordon | yeah | 22:04 |
| freemangordon | well, I think moving the version check back is ok | 22:04 |
| freemangordon | either ways we carry our own patches | 22:04 |
| tmlind | yeah ok let me type up some kind of description | 22:05 |
| tmlind | seems to implement these functions we should just return two formats DRM_FORMAT_ARGB8888 and DRM_FORMAT_XRGB8888 looking at the wlroots fallback handling | 22:06 |
| tmlind | the pvr mesa hacks have some comments about pvr having multiple compatible options where some cannot be shown | 22:07 |
| tmlind | maybe we don't even need to call the blobs to implement this, but that can be always done later | 22:08 |
| freemangordon | I think version check is ok | 22:08 |
| tmlind | yup | 22:09 |
| freemangordon | that way wlroots will fallback | 22:09 |
| freemangordon | to those 2 formats | 22:09 |
| freemangordon | I will make a proper patch (along with version fix) afte I am back from holidays (sunday, most-probably) | 22:10 |
| freemangordon | unless someone beats me to it | 22:10 |
| freemangordon | I still thinks it make sense to open an issue on mesa bugtracker | 22:10 |
| tmlind | ok | 22:15 |
| tmlind | meanwhile, here's the partial revert for folks to play with like we discussed: http://muru.com/linux/d4/0001-egl-dri2-Workaround-for-EGL_EXT_image_dma_buf_import.patch | 22:17 |
| tmlind | anyways, enough of this, ttyl | 22:20 |
| Wizzup | uvos: sounds good @ temp fix | 22:24 |
| Wizzup | uvos: no rus | 22:24 |
| Wizzup | h | 22:24 |
| freemangordon | tmlind: actually, checking for verision only is enough (and correct) | 22:29 |
| freemangordon | *version | 22:29 |
| freemangordon | but anyway, I'll fix that properly | 22:30 |
| tmlind | freemangordon: oh maybe all we really need to do is implement something like etna_screen_query_dmabuf_modifiers() | 22:30 |
| freemangordon | we have issue with formats, not modifiers :) | 22:30 |
| freemangordon | but yeah, something like that | 22:31 |
| tmlind | should not be any need to call the blobs | 22:31 |
| freemangordon | right | 22:31 |
| freemangordon | also, see https://github.com/maemo-leste/sgx-ddk-um/blob/master/dbm/dbm.c#L467 | 22:32 |
| tmlind | oh right :) | 22:33 |
| freemangordon | tmlind: still, I think it will be good if we have chromeos pvr_dri_support to feed IDA with, to see what they do there | 22:34 |
| tmlind | sure, no docs | 22:34 |
| Boshtannik | Hi to all! | 22:35 |
| Boshtannik | How can I be notified about keyboard mapping unmatching to be fixed? | 22:37 |
| tmlind | hi, sounds like you need to set up a user account at github and subscribe for notifications | 22:41 |
| tmlind | freemangordon: probably the old modifiers code did not work as things have changed around, see c8a0660ab4d1 ("etnaviv: advertise supported dmabuf modifiers") | 22:41 |
| tmlind | seems like pscreen->query_dmabuf_modifiers needs to be implemented as the patch removing 15 version check adds checks for those | 22:42 |
| freemangordon | but this is for gallium, no? | 22:43 |
| freemangordon | not for egl | 22:43 |
| tmlind | argh you're right | 22:44 |
| Boshtannik | Ahh github? But it was microsoft ed.. | 22:45 |
| sicelo | or manually visit the page at regular intervals, without an account. you can choose your poison ;-) | 22:46 |
| freemangordon | tmlind: hmm, see g_asFormats in pvrutil.c | 22:47 |
| freemangordon | but yeah, it is about dma_buf | 22:48 |
| freemangordon | anyway, I will stop for today | 22:48 |
| tmlind | freemangordon: yeah and note how we now have .bQueryDmaBufFormatsExclude unused | 22:48 |
| freemangordon | night! | 22:48 |
| tmlind | night, me out of here too | 22:48 |
| Boshtannik | Have built python 3.10 on my n900) | 22:50 |
| freemangordon | tmlind: yeah, maybe I shaved too much code, will see what can be done | 22:52 |
| freemangordon | uvos: BTW, I think it makes sense to not disable the second core while charging | 23:02 |
| uvos | freemangordon: sure yeah | 23:25 |
| uvos | freemangordon: did you see the config option? | 23:25 |
| uvos | (to disable this entirely) | 23:25 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!