Wizzup | just debian things: installing hostapd means it gets auto started on boot, and if you configure it (via config file) for usage at some point, it will interfere with wifi | 00:55 |
---|---|---|
Wizzup | and I removed it from the runlevel, but every time it's updated, it gets added back to the runlevel | 00:55 |
uvos | more like just devuan things | 01:09 |
uvos | since debian on systemd dosent have this problem | 01:09 |
Wizzup | uvos: it doesn't autostart services? | 01:09 |
uvos | it dose but you can ask systemd if the user disabled it or something | 01:09 |
uvos | (not sure how it works exactly but it only enables the service once) | 01:09 |
uvos | might just be that the systemd dpkg scripts are better idk | 01:10 |
cockroach | you should be able to do the same thing with normal init scripts if you do it the "proper way" (rather than just removing the symlink). I think. | 01:10 |
cockroach | i.e. with update-rc.d | 01:11 |
Wizzup | uvos: I think this is problem with dpkg | 01:12 |
Wizzup | I think it probaly does the same thing | 01:12 |
Wizzup | when I said 'I removed it from the runlevel', I meant 'rc-update del hostapd' | 01:13 |
Wizzup | mbut maybe update-rc.d does more | 01:13 |
cockroach | okay, sorry for the noise then | 01:13 |
Wizzup | very welcome :) | 01:13 |
inky | jk000 if you come and see this - so you see the mouse pointer on the screen? | 01:20 |
Wizzup | bencoh: btw, I see this in wpa_supplicant: <3>CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN | 02:42 |
Wizzup | bencoh: per nl80211_reg_beacon_hint_event in hostap/src/drivers/driver_nl80211_event.c I assume that actually it does change the regulatory domain based on other beacons | 02:42 |
Wizzup | didn't check it really hard, but wanted to follow up on that | 02:42 |
Wizzup | looks like wpa_supplicant has various sources of regdom info | 02:42 |
Wizzup | see reg_init_str in hostap/wpa_supplicant/events.c | 02:42 |
Wizzup | freemangordon: ^^ | 02:43 |
Wizzup | so those beacon hints cause EVENT_CHANNEL_LIST_CHANGED which does seem to change frequencies and such | 02:46 |
Wizzup | so it looks like the "magic" might just work | 02:47 |
Wizzup | of course, we can do more, based on modem status for example. | 02:47 |
ravelo | 'lo | 09:15 |
diejuse | Hi, I am trying with ARM instead ARM64. I am trying to chroot Maemo Leste on an old ARM Android Phone. I get many error messages like "failed to get XImage of pixmap". Any clue/help to solve it? | 09:28 |
bencoh | Wizzup: oh, interesting | 10:23 |
bencoh | it's really "magic" :) | 10:23 |
uvos | diejuse: sounds more like a 3d driver problem than an x problem per say | 11:00 |
uvos | or bitedness problem even | 11:00 |
Wizzup | uvos: it could be older android not supporting X as well | 11:04 |
diejuse | uvos: however if I open the apps through Xephyr it works and I don't get those messages | 11:04 |
Wizzup | Xephyr might not be accelerated | 11:05 |
diejuse | is there any way to remove Hildon's animations to make it faster? | 11:14 |
Wizzup | diejuse:: not trivially, no, you won't have a good experience without 3d generally | 11:14 |
inky | diejuse, i don't really understand what you are doing, but would like to. so you have a leste chroot on an android phone. okay. that would work in commandline. then did you use some X surface for android? | 11:17 |
diejuse | I use "XSDL XServer" app like X Window System / X11 server | 13:06 |
diejuse | inky | 13:06 |
diejuse | Now I'm testing it on an old mobile, on an Xperia Pro | 13:09 |
diejuse | I want to see if Maemo Leste is usable through the chroot technique on old mobiles. | 13:10 |
diejuse | The script I made for ARM64 does not work at all because it gives me graphical errors when I open the applications. But if I do a workaround using "xephyr" I can get it to work. | 13:14 |
Wizzup | diejuse: so it's likely related to 3D (driver) stuff | 13:26 |
diejuse | Wizzup: It seems to be so. I love Xephyr. I also fixed the drop down menu problem with Xephyr. | 13:29 |
diejuse | The only problem is that the performance drops a bit. | 13:30 |
uvos | diejuse: you are unlikely to have that mutch luck with the pro really | 13:30 |
uvos | a android device that old, what dose it run linux 2.6.x? | 13:30 |
uvos | im kinda supprised glibc still has support for the kernel its running... | 13:31 |
uvos | looks like current glibc needs at least 3.2 | 13:34 |
uvos | our glibc is older so maybe it works with 2.6 | 13:34 |
uvos | if so your setup will die with the upgrade to debian/devuan 11 | 13:34 |
Wizzup | there's always mainlining :) | 13:35 |
diejuse | uvos: When I first entered this channel, you told me that what I was trying was not going to work. Now I will surprise you again. :P | 13:36 |
uvos | heh | 13:36 |
uvos | yeah maybe im overly sceptic | 13:36 |
uvos | but still chroot over ever more ainchent android underpinnings its unsustanable | 13:37 |
diejuse | Firefox and Chromium don't work well on the Xperia Pro but Dillo works quite well. | 13:37 |
diejuse | I will make another video and put documentation. | 13:38 |
uvos | so what kernel is the pro running? | 13:38 |
diejuse | Yes but first I had to update to Android 7 (Lineage OS 14.1) | 13:38 |
uvos | right but lineageos rarely upgrades the kernel | 13:39 |
uvos | they mostly just work with the vendor kernel as long a possible | 13:39 |
uvos | and then drop the device when not | 13:39 |
diejuse | With Android 6 (CyanogenMod 13) it didn't work | 13:39 |
uvos | they dropped a huge amount of devices after 14 for this reason | 13:39 |
uvos | since later android needs a newer kernel | 13:39 |
diejuse | Similarly, I managed to get Maemo to work on a Blackberry Key 1 (Android 7) but it didn't work for me on a Blackberry Priv (Android 6) | 13:40 |
diejuse | uvos: I understand | 13:40 |
uvos | go to settings -> about phone -> android version | 13:41 |
uvos | and tell my "Kernel version" for the devices | 13:41 |
uvos | im curious | 13:41 |
diejuse | one moment | 13:41 |
diejuse | Uvos: Kernel 3.4.0-LX+ | 13:42 |
uvos | ok your safe for now :) | 13:42 |
diejuse | >3,2 | 13:42 |
diejuse | >3.2 | 13:42 |
uvos | barely made it :P | 13:42 |
uvos | what device was what? | 13:42 |
diejuse | hehe | 13:43 |
diejuse | the device? Sony Xperia Pro MK16 | 13:43 |
diejuse | beauty device with physical keyboard | 13:43 |
diejuse | I bought it second-hand for 30 euros and did several experiments on it. | 13:44 |
diejuse | I have got xperia mini pro sk17 too. Another beauty device. | 13:45 |
Wizzup | uvos: for the record I did chat some more with fmg about the whole wlancond and such, and it does do some sensible things like change wireless power saving state if a voip call is active, and other stuff like that, not yet sure where we could fit that, so we might ultimately need a daemon to manage some of that | 13:47 |
Wizzup | there's no immediate solution required and for now we'll add stuff to libicd-network-wpasupplicant (like power saving etc) | 13:47 |
Wizzup | we'll deal with it once we can make calls and voip calls ;) | 13:48 |
uvos | "whatever manages modem state" still seams like the sane awnser | 13:49 |
uvos | regarding voip, if we do decide to mangage modem state in mce, it allready knows the call state so a module could do this with almost no extra code | 13:49 |
Wizzup | yes, but then mce would have to do all wireless power saving setting | 13:51 |
uvos | we could make a global decission that "power managment is mces job" or something like that if you like | 13:51 |
Wizzup | and then it needs IAP knowledge etc | 13:51 |
uvos | or a seperate modem manager deamon | 13:51 |
Wizzup | It does get a bit messy | 13:51 |
Wizzup | right | 13:51 |
Wizzup | in any case, it's not super relevant now, just wanted to follow up | 13:51 |
Wizzup | and yes, btw, a modem module for mce would be good, to online the modem and such | 13:51 |
uvos | no new modules until we unfork our mces :) | 13:51 |
Wizzup | yeah, yeah ;) | 13:54 |
uvos | btw im not sure we have to do anything special for voip | 13:58 |
uvos | since kernel has dynamic power-saving and will do latency management based on packet behavior | 13:59 |
uvos | and the old network latancy interface is gohne | 13:59 |
uvos | so you cant tell the kernel anymore that you need real time | 14:00 |
uvos | (and its also not needed anymore)_ | 14:00 |
Wizzup | I think 'iw set <dev> power_save on' on n900 will make packet latency go up a _lot_ even when active | 14:01 |
Wizzup | so probably it will be | 14:01 |
uvos | right but the interface that allowed userspace to detemine what latency is acceptable (what wlancond almost certenly used) is gone afaik | 14:03 |
uvos | so you can oly turn dps off | 14:03 |
bencoh | iirc there are 3 mods in maemo5, and two of them are definitely bearable latency-wise | 14:04 |
bencoh | the super-low-power one is a bit harsh (still iirc) | 14:04 |
bencoh | but that's the kind of thing you'll notice if you ssh (or other low-latency activity) anyway | 14:05 |
Wizzup | uvos: possible @ power saving granularity | 14:12 |
tmlind | Wizzup: hmm i naturally backported the musb breaking pinephone fix to the droid4-pending-v5.10 and later trees too.. | 18:25 |
tmlind | so that would explain the reports about usb notworking networking | 18:25 |
uvos | parazyd: ^^^ | 18:27 |
tmlind | i'll go push the fix for the fix to all the droid4-pending-v5.10 and later branches | 18:28 |
uvos | we dont need 5.12 | 18:29 |
uvos | leste is on 5.10 and 5.11 and non leste use is 5.13 | 18:29 |
uvos | for me at least | 18:29 |
tmlind | ok | 18:32 |
tmlind | we really should get m-l kernel working with the ddk-1.17 :( | 18:34 |
uvos | yeah :| | 18:36 |
bencoh | any link to the musb thing? | 18:36 |
tmlind | bencoh: https://lore.kernel.org/r/20210528140446.278076-1-thomas.petazzoni@bootlin.com | 18:41 |
bencoh | thanks! | 18:43 |
uvos | tmlind: btw your ttys0 patch + disabling sysreq and disabling kernel consol on serial port makes the boot failures with usb pluged in dissapear | 18:44 |
uvos | so mabye add that patch to the droid4-pending-* branches | 18:45 |
tmlind | uvos: ok cool | 18:45 |
uvos | but the fact that i have to disable kernel console on serial suggests the port is still misbehaveing somehow | 18:46 |
tmlind | yeah.. | 18:47 |
uvos | (ie hanging or soemthing) | 18:47 |
tmlind | did you set sysrq to 0 in .config? | 18:47 |
uvos | yeah | 18:47 |
tmlind | hmm | 18:47 |
uvos | but it dont know if its needed | 18:47 |
tmlind | let's wait on that one a bit then | 18:47 |
uvos | that alone was not nessecary | 18:47 |
uvos | or enough rather | 18:47 |
tmlind | yeah | 18:47 |
uvos | i had to also disable the output | 18:47 |
uvos | ok @ wait | 18:48 |
tmlind | parazyd: pushed out updated droid4-pending-v5.10 and droid4-pending-v5.11 to github with latest stable stuff merged in + usb networking fix applied | 18:48 |
tmlind | parazyd: only compile tested those branches, i've been using the usb fix for few days locally though. there was also a trivial charger merge conflict so might be worth testing | 18:49 |
uvos | same here usb fix has been fine on 5.11 | 18:49 |
tmlind | ok | 18:49 |
tmlind | uvos: i'll wait on aplying the usb fix to the droid4-pending-v5.13 branch and will just merge in -rc5 that should have the fix | 18:50 |
uvos | tmlind: ok :) | 18:50 |
tmlind | no other users for that branch beyong you and i probably right now :) | 18:50 |
uvos | right :P | 18:51 |
tmlind | uvos: fyi somehow wl12xx produces always a sdio read error on first boot on mz617 | 18:51 |
tmlind | uvos: and power key does not get detected by kexecboot | 18:51 |
tmlind | uvos: so i can't select the kexecboot kernel to boot right now.. | 18:52 |
uvos | ok ill check it out once Wizzup's package arrives :) | 18:52 |
tmlind | uvos: ok, i don't really have a much of a kernel patch for it yet, just nothing in it really just the compatible | 18:53 |
uvos | thats fine | 18:53 |
tmlind | uvos: will send to you when you get the package, been trying to figure out the lcd panel | 18:53 |
tmlind | the lcd seems to be dsi to a dsi-to-lvds bridge | 18:53 |
uvos | mostly mapphone-common.dtsi (or what the name is) should have it coverd except lcd and some sensor specifics | 18:54 |
uvos | interesing | 18:54 |
uvos | wierd way to do it | 18:54 |
tmlind | something similar is in exynos5250-arndale.dts, hopefully that compatible will work here too | 18:54 |
tmlind | it's a toshiba tc358765 that hopefully is very similar to tc358764.c that the mainline kernel driver handles | 18:55 |
tmlind | no idea what the difference between tc358764 and tc358765 is if anybody cares to try to research :) | 18:56 |
uvos | i++ :P | 18:56 |
tmlind | heh | 18:56 |
tmlind | or a typo | 18:56 |
tmlind | or charge more money from a big custome | 18:56 |
tmlind | r | 18:57 |
tmlind | google search produced this answer: | 19:00 |
tmlind | The TC358764 supports panels up to 1366x768, with 24 bits per pixel. The TC358765 supports panels up to 1920x1200, with 18 bits per pixel. Applicable to a range of mobile product platforms such as MIDs, netbooks, smartbooks and eBooks. | 19:01 |
tmlind | i guess i need to somehow fix the kexecboot power key for mz617 first | 19:03 |
uvos | the keycode is likey just different | 19:04 |
uvos | check in android | 19:04 |
tmlind | noisy dmesg for v3.0.8 kernel on it shows KEY_POWER debug statements for each press and release.. | 19:05 |
uvos | hmm | 19:05 |
uvos | ok thats wierd then | 19:05 |
tmlind | it should be the same cpcap power key as on others | 19:05 |
tmlind | hmm maybe it does not work on xt894 either, let me check | 19:05 |
uvos | it certly works on xt875 | 19:06 |
uvos | so kexecboot binary isent totaly broken | 19:06 |
tmlind | you boot to mainline kernel though? | 19:06 |
uvos | but different kernel ofcourse | 19:06 |
uvos | right | 19:06 |
uvos | but ist not a fundamental bug in kexecboot im saying | 19:06 |
tmlind | heh power key won't do anything for xt894 either with kexecboot :) funny nobody noticed | 19:07 |
tmlind | so the keycode must not be KEY_POWER, or it's not advertised as a proper keyboard | 19:08 |
tmlind | hmm there's define VERY_LONG_HOLD_REBOOT, maybe it just needs to be pressed for longer.. | 19:11 |
tmlind | nope, maybe kexecboot only supports one keyboard or something | 19:15 |
uvos | that would not work on xt875 | 19:17 |
uvos | xt875 has power and volume on different devices | 19:17 |
uvos | both work | 19:17 |
uvos | not sure why they used the keyboard matrix for 2 keys btw | 19:20 |
uvos | maybe its just inherited form/so that its the same as xt862 or something | 19:20 |
tmlind | uvos: but xt875 uses mainline kernel with kexecboot, not v3.0.8 kernel | 19:21 |
uvos | tmlind: sure but it still has 2 keyboard event devices | 19:21 |
uvos | and kexeboot picks up both | 19:21 |
uvos | so its not that | 19:21 |
tmlind | uvos: ok | 19:21 |
uvos | btw android there is getevent | 19:22 |
uvos | == evtest | 19:22 |
uvos | (just about) | 19:22 |
uvos | if you have root | 19:22 |
tmlind | ok still have usable android on mz617 | 19:23 |
tmlind | so is getevent there built-in? | 19:23 |
uvos | its part of asop | 19:23 |
uvos | dosent enforce that they ship it | 19:24 |
tmlind | ok | 19:24 |
uvos | im booting los on d4 | 19:24 |
tmlind | ok | 19:24 |
uvos | goes absolutly crazy with events on d4 | 19:25 |
tmlind | does it generate KEY_POWER? | 19:26 |
uvos | i cant red anything | 19:26 |
uvos | the accel is a event device | 19:26 |
uvos | and it totaly swamps everything | 19:27 |
tmlind | heh | 19:27 |
uvos | power goes | 19:29 |
uvos | 001 006b | 19:29 |
uvos | looks like its KEY_END | 19:30 |
tmlind | huh? | 19:32 |
uvos | yeah its KEY_END | 19:33 |
uvos | getevent -lt /dev/input/event2 | 19:33 |
uvos | and press power | 19:33 |
tmlind | weird | 19:33 |
uvos | yeah | 19:33 |
uvos | i absolutly hate useing the terminal in los | 19:34 |
uvos | there is no ctrl | 19:34 |
uvos | how grr | 19:34 |
tmlind | ok event3 on mz617 stock android, but KEY_END yeah | 19:35 |
tmlind | ok i'll patch kexecboot for that | 19:35 |
tmlind | userspace tweaks it in android or what? | 19:35 |
uvos | great | 19:35 |
uvos | cant parse | 19:35 |
uvos | what userspace tweaks | 19:35 |
tmlind | hmm no userspace gets run with utagboot though | 19:35 |
uvos | oh the key_end | 19:36 |
tmlind | i'm not seeing KEY_END in the v3.0.8 kernel sources | 19:36 |
uvos | yeah no must be the kernel somehow | 19:36 |
tmlind | for the cpcap driver | 19:36 |
uvos | no idea | 19:36 |
tmlind | weird | 19:37 |
tmlind | uvos: ok pushed out updated droid4-xyboard-kexecboot-2017.11 to github, will email out the patch with your in cc | 19:58 |
tmlind | thanks for helping to debug that one :) | 19:58 |
uvos | you are ofc welcome :) | 19:59 |
tmlind | kexecboot patch sent, detaching from keyboard now, ttyl | 20:01 |
parazyd | tmlind, uvos: Thanks for the notification for the patch | 21:33 |
parazyd | I'll get it ready soon | 21:33 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!