| Wizzup | btw - I don't get the charging led pattern on the n900 | 00:19 |
|---|---|---|
| Wizzup | uvos: I have his email, maybe ping him on the pr? | 00:19 |
| uvos | is it enabled? | 00:20 |
| uvos | could you give me mce log? | 00:20 |
| uvos | use openrc to stop mce | 00:20 |
| * Wizzup makes a note to do that tomorrow | 00:21 | |
| Wizzup | btw, something I was wondering about, I wonder if it makes sense to set up syslog in such a way that it is much easier to share debug logs | 00:21 |
| Wizzup | we could have /var/log/maemo/daemons/mce.log | 00:21 |
| uvos | and run it with mce --verbose --verbose in a "su -" (ie clean env) root shell | 00:21 |
| uvos | Wizzup: not usefull without makeing mce verbose | 00:21 |
| uvos | in this case at least | 00:21 |
| uvos | but yeah sure | 00:22 |
| uvos | anyhow do that and then plug the charger in and out a couple of times with some time in between, 2 min should od | 00:22 |
| uvos | *do | 00:22 |
| Wizzup | why with time in between? | 00:23 |
| uvos | to see if udev is reporting events | 00:23 |
| uvos | er upower | 00:23 |
| uvos | mce will log when it gets upower events | 00:23 |
| uvos | but they come in infrequently | 00:23 |
| Wizzup | running now | 00:23 |
| uvos | also make sure the pattern is enabled in the first place :P | 00:24 |
| Wizzup | it is | 00:24 |
| Wizzup | uvos: it seems to get the messages right away | 00:24 |
| Wizzup | but it only seems to change patterns on charger off it seems | 00:24 |
| Wizzup | hmm: mce: LED pattern PatternBatteryCharging deactivated | 00:25 |
| uvos | ok | 00:25 |
| uvos | no idea who should be starting the pattern | 00:25 |
| uvos | maybe the upower module | 00:25 |
| Wizzup | mce | 00:25 |
| uvos | i mean in mce | 00:25 |
| Wizzup | oh | 00:25 |
| Wizzup | https://wizzup.org/mce.log | 00:25 |
| Wizzup | btw: PatternBatteryCharging = true | 00:27 |
| uvos | yeah sure log also registers it mce: led-dbus: PatternBatteryCharging enabled | 00:29 |
| uvos | hmm | 00:30 |
| uvos | something is off here | 00:31 |
| uvos | mce: pattern: PatternError, active: 0 comes from led-lysti | 00:31 |
| uvos | (grr annoying legacy modules that dont annouce what module the log statment comes from) | 00:32 |
| uvos | but the patterns are registerd twice for some reason | 00:32 |
| uvos | nvm | 00:33 |
| uvos | its just really verbose | 00:33 |
| uvos | https://github.com/maemo-leste/mce/blob/abc429bef65971274d3fea45cc73ced4d617757e/src/modules/battery-upower.c#L246 | 00:38 |
| uvos | its there | 00:38 |
| uvos | maybe check if it executes this via gdb | 00:39 |
| uvos | if you actviate the pattern via dbus dose it show? | 00:39 |
| Wizzup | sure, let me try | 00:39 |
| Wizzup | do you have a way to do it handy? | 00:39 |
| Wizzup | ah: dbus-send --system --type=method_call --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_led_pattern_activate string:"PatternCommunicationIM" | 00:40 |
| uvos | yeah | 00:40 |
| uvos | also check the policy in mce ini | 00:40 |
| uvos | looks like it has policy 4: only show pattern if the display is off, or if in acting dead | 00:41 |
| Wizzup | that is fine I think | 00:41 |
| uvos | sure if your not expecting to see it while the display is on ;) | 00:42 |
| Wizzup | I am not | 00:42 |
| Wizzup | hm the ts on my n900 is not happy atm | 00:43 |
| Wizzup | (was updating) | 00:43 |
| Wizzup | ah, dist-upgrade was required to remove the old rotation support | 00:44 |
| Wizzup | I don't see anything when I try to activate the pattern I think | 00:45 |
| Wizzup | wait.. | 00:45 |
| Wizzup | manually activating it works | 00:45 |
| Wizzup | and it disappears on display on, and then comes back when display goes off | 00:45 |
| Wizzup | so something just doesn't trigger it I think in mce upower | 00:45 |
| uvos | Wizzup: ok so the dbus call results in the exact same datapipe call here: https://github.com/maemo-leste/mce/blob/abc429bef65971274d3fea45cc73ced4d617757e/src/modules/led-dbus.c#L101 | 00:47 |
| uvos | so clearly its not getting here: https://github.com/maemo-leste/mce/blob/abc429bef65971274d3fea45cc73ced4d617757e/src/modules/battery-upower.c#L246 | 00:47 |
| uvos | not sure why that would be | 00:47 |
| Wizzup | I can step through it later if you'd like | 00:47 |
| Wizzup | at least I got my droid3 static kernel to boot, tomorrow I will try to load kexecboot | 00:48 |
| Wizzup | the display not turning on has me a bit worried that my config isn't ok yet though :P | 00:48 |
| uvos | ok | 00:48 |
| uvos | well some progress at least | 00:48 |
| Wizzup | yeah | 00:48 |
| uvos | wait lol | 00:49 |
| uvos | that execute_datapipe is bullshit | 00:49 |
| uvos | USE_CACHE | 00:49 |
| uvos | its retiggering the last input pattern | 00:49 |
| uvos | which is null in this case | 00:50 |
| Wizzup | ah | 00:50 |
| Wizzup | good eye | 00:50 |
| uvos | ok ill fix it tomorrow | 00:51 |
| Wizzup | cool | 00:51 |
| mighty17[m] | tried to run plamo with powervr (on pmOS) and i get https://pastebin.com/rqZAMp6j | 10:04 |
| mighty17[m] | tmlind: maybe you have any clues, are we missing egl extensions again? | 10:04 |
| uvos | Wizzup: mce chargeing pattern should be fine now | 10:50 |
| uvos | (once ci finishes building it) | 10:51 |
| Wizzup | uvos: great | 10:51 |
| Wizzup | btw, is it hard to disable the green led going on by default on the d4, I recall I asked before | 10:51 |
| Wizzup | is this also a 'cpcap magic' thing? | 10:52 |
| uvos | yeah its cpcap magic | 10:52 |
| Wizzup | ok | 10:52 |
| Wizzup | it tends to mess with the notifications | 10:52 |
| uvos | there might be a register | 10:52 |
| uvos | or it might be controlled by cpcap mcu | 10:52 |
| Wizzup | ok, no big deal really, just wondered | 10:52 |
| uvos | never looked | 10:52 |
| Wizzup | regardin cpcap mcu, should we ever try to dump the fw and compile it or something? | 10:52 |
| Wizzup | decompile* | 10:53 |
| uvos | sure | 10:53 |
| uvos | but idk how | 10:53 |
| uvos | moto never updated the fw | 10:53 |
| Wizzup | it's a ST Ericsson CPCAP 6556002? | 10:54 |
| uvos | im not sure cpcap even allows you to read it | 10:54 |
| uvos | depends | 10:54 |
| uvos | there are 2 versions used | 10:54 |
| uvos | they are not 100% compatible | 10:55 |
| Wizzup | well it probably doesn't allow reading, but there are tools that might be able to do it | 10:55 |
| uvos | sure | 10:56 |
| uvos | anyhow its a MC13783UG hevaly modified to motorola specs and then oemed by nxp and ericsson | 10:57 |
| uvos | critically the MC13783UG has no uc | 10:57 |
| Wizzup | fun: The MC13783 supports booting on USB. The boot mode is entered by the USBEN pin being forced high | 11:02 |
| Wizzup | which enables the USB transceiver and the VUSB regulator supplied from VINBUS. The 1.5 K pull up is | 11:02 |
| Wizzup | connected to UDP and the USB transceiver will operate in the mode as determined by the UMOD0 and | 11:02 |
| Wizzup | UMOD1 pins. | 11:02 |
| Wizzup | ok I suppose maybe just understanding the android src for cpcap might be an easier way to understand what it does | 11:07 |
| uvos | sure | 11:07 |
| uvos | it uploades some code snypets to the mcu | 11:07 |
| uvos | couple 100 bytesworth | 11:07 |
| uvos | and calls these macros | 11:07 |
| uvos | and then enables and disables them | 11:08 |
| uvos | there is also a mailbox it uses to comunicate with the mcu | 11:08 |
| Wizzup | ok | 11:09 |
| uvos | so on n900 | 11:32 |
| uvos | when the headphone is plugged in | 11:32 |
| uvos | where dose this go? | 11:32 |
| uvos | interface wis | 11:32 |
| uvos | e | 11:32 |
| Wizzup | let me try now | 11:34 |
| Wizzup | /dev/input/event6:RX-51 AV Jack | 11:36 |
| Wizzup | Supported events: | 11:36 |
| Wizzup | Event type 0 (EV_SYN) | 11:36 |
| Wizzup | Event type 5 (EV_SW) | 11:36 |
| Wizzup | Event code 2 (SW_HEADPHONE_INSERT) state 0 | 11:36 |
| Wizzup | Event code 4 (SW_MICROPHONE_INSERT) state 0 | 11:36 |
| Wizzup | Event code 8 (SW_VIDEOOUT_INSERT) state 0 | 11:36 |
| Wizzup | Event: time 1633599392.339202, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1 | 11:36 |
| Wizzup | Event: time 1633599392.339202, type 5 (EV_SW), code 4 (SW_MICROPHONE_INSERT), value 1 | 11:36 |
| Wizzup | I think that's it | 11:37 |
| Wizzup | related https://wiki.merproject.org/wiki/Adaptations/faq-hadk#Audio_not_routed_to_headphones | 11:37 |
| uvos | this seams wierd tho | 11:38 |
| uvos | im sure the mainline intention isent to use the evdev interface to report the headphone jack | 11:38 |
| uvos | how dose this work on laptops | 11:38 |
| uvos | my pc dosent have sutch an event | 11:39 |
| Wizzup | maybe acpi or something? | 11:39 |
| Wizzup | actually it might be in alsa directly | 11:39 |
| Wizzup | iirc | 11:39 |
| uvos | dose plugging in the headphone jack on n900 switch pulse to that sink ? | 11:39 |
| Wizzup | https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/558 | 11:40 |
| Wizzup | it expects to get it through alsa | 11:40 |
| parazyd | On laptops there's an ACPI event for plug in | 11:40 |
| Wizzup | it seems to be in kernel alsa interface if I read it correctly | 11:41 |
| parazyd | Yeah in /proc/asound I think | 11:41 |
| Wizzup | don't know the exact api/interface | 11:41 |
| uvos | ok | 11:42 |
| uvos | well i figured out that you can unmask an intterupt bit and cpcap fires its general intterupt when the hp gets plugged in | 11:42 |
| uvos | thats not enough information by itself (it also fires when its unplugged) | 11:42 |
| uvos | but now i need to know where the information is even supposed to go | 11:43 |
| bencoh | as long as you can read some register, it should be enough | 11:43 |
| parazyd | http://ix.io/3B5j | 11:43 |
| uvos | i cant | 11:43 |
| bencoh | oh | 11:43 |
| bencoh | well | 11:43 |
| uvos | bencoh: i cant there is none | 11:43 |
| bencoh | right, you mentioned that before | 11:43 |
| uvos | bencoh: the android kernel dose some werd stuff | 11:43 |
| uvos | bencoh: it comunicates with the mcu | 11:43 |
| bencoh | weird in what way? | 11:43 |
| uvos | well its not that wierd | 11:43 |
| Wizzup | https://01.org/linuxgraphics/gfx-docs/drm/sound/designs/jack-controls.html | 11:43 |
| bencoh | sounds like something we could do as well I guess | 11:43 |
| uvos | it just communicates with the propriatary fw | 11:43 |
| Wizzup | btw, looks like kernel makes input devices on my laptop too | 11:44 |
| Wizzup | *through* alsa | 11:45 |
| Wizzup | (probably using the phantom_jack=true) | 11:45 |
| Wizzup | uvos: not sure if you need more pointers but it looks like include/sound/jack.h it helpful, as is sound/soc/soc-jack.c | 11:49 |
| bencoh | yeah, alsa uses evdev to report jack events | 11:49 |
| bencoh | at least that's how many devices do it | 11:49 |
| Wizzup | you need to register the jack controls and then use snd_soc_jack_report like other drivers do (grep -r snd_jack_report sound/soc/) | 11:49 |
| Wizzup | bencoh: yeah alsa has an option to do this, but pulse doesn't use that alsa interface, it's just an extra to not have drivers re-implement input devices IIUC | 11:50 |
| bencoh | indeed | 11:50 |
| bencoh | well, iiuc as well | 11:50 |
| bencoh | (alsa isn't exactly the simplest linux API ...) | 11:51 |
| uvos | asoc drivers dont use snd_jack_report | 11:53 |
| Wizzup | huh? | 11:53 |
| Wizzup | they use snd_soc_jack_report | 11:53 |
| uvos | no existing driver uses that fn | 11:53 |
| Wizzup | which is provided by sound/soc/soc-jack.c | 11:53 |
| uvos | asoc drivers a genererally are really ideosnycranous | 11:53 |
| Wizzup | random pick from the grep: | 11:54 |
| Wizzup | sound/soc/codecs/rt5645.c:snd_soc_jack_report(rt5645->hp_jack, report, SND_JACK_HEADPHONE); | 11:54 |
| uvos | ah snd_soc_jack_report | 11:55 |
| uvos | not snd_jack_report | 11:55 |
| uvos | ok | 11:55 |
| Wizzup | yeah snd_soc_jack_report wraps snd_jack_report | 11:56 |
| Wizzup | I had the same confusing when I was grepping just now | 11:56 |
| uvos | ok | 12:01 |
| uvos | by assumeing that the jack is empty when the kernel starts i can make something that works at least in a proof of concept way | 12:02 |
| Wizzup | cool | 12:10 |
| uvos | actually its not that simple | 12:20 |
| uvos | we only have a audio codec not a snd soc driver | 12:20 |
| uvos | and use the generic driver | 12:20 |
| uvos | so we cant snd_soc_card_jack_new | 12:20 |
| uvos | so i need to figure out how to register a jack with the generic soc driver | 12:20 |
| uvos | asoc really is... | 12:21 |
| uvos | dificult to weed through understand | 12:21 |
| tmlind | uvos: oh so you figured out some interrupt happens when pluggin/unplugging the headset? | 15:29 |
| tmlind | uvos: which interrupt is it triggering? | 15:29 |
| tmlind | mighty17[m]: sorry i have really no idea on what all goes wrong with the pvr stuff :( barely have wlroots working | 15:30 |
| uvos | CPCAP_IRQ_HS | 15:31 |
| uvos | maybe that should not have been so suprizing :P | 15:31 |
| uvos | <&cpcap 9 0>; | 15:32 |
| uvos | on mainline | 15:32 |
| uvos | but since there is not gpio to read when the irq fires | 15:33 |
| uvos | im not sure how to determine if the headset was plugged or unplugged | 15:33 |
| tmlind | oh ok, maybe that's all there is to it :) we just need the direction | 15:39 |
| uvos | well the mainline kernel also querys the mcu | 15:40 |
| uvos | but it looks like this is just to determine what kind of plug | 15:40 |
| tmlind | ok | 15:40 |
| uvos | yeah wrt the direction | 15:40 |
| tmlind | i think we just need to read the status register for direction as it's not a gpio controller | 15:41 |
| uvos | ok yeah | 15:41 |
| uvos | i need to know if TRIGGER_RISING or TRIGGER_FALLING was the casue of the irq fireing | 15:42 |
| uvos | i guess i have to read the status regsiter myself | 15:42 |
| uvos | or is there an api for that | 15:42 |
| uvos | (other than reading it in the regmap) | 15:42 |
| tmlind | hmm well see what we already do in cpcap_charger_get_ints_state() | 15:42 |
| uvos | ok | 15:43 |
| tmlind | sure it will be potentially racy with plugging and unplugging :) | 15:43 |
| uvos | especcaly if its not hw debounced | 15:43 |
| tmlind | yeah | 15:43 |
| uvos | (duno if it is) | 15:43 |
| Wizzup | https://wizzup.org/sigmakey.png getting somewhere... | 15:52 |
| tmlind | Wizzup: i bet a beer all it does is enable the gsm frequencies in the nvram reg :) maybe do a tcmdrw dump before and after? | 15:53 |
| uvos | well hopefully not since that would not be sufficant to remove the simlock | 15:54 |
| Wizzup | tmlind: we will find out soon - this is the droid 3 that is networked locked and will not connect to anything even with the freqs set | 15:54 |
| Wizzup | I have 7 more here, so if that works we can try to do those dumps | 15:55 |
| tmlind | ok, interesting | 15:55 |
| Wizzup | looking forward to that beer if it works :P | 15:55 |
| * dreamer puts stack of droid4s on buZz desk | 15:55 | |
| tmlind | yeh me too :) | 15:55 |
| uvos | but d3 look mutch fancier on a desk | 15:56 |
| tmlind | i'm pretty sure bionic is only connecting to 3g with some sim cards here, not sure why, the frequency should be the same not depending on the operator | 15:56 |
| tmlind | uvos: are you able to use your bionic with 3g? | 15:56 |
| uvos | yes | 15:57 |
| tmlind | ok | 15:57 |
| uvos | it worked once on o2 | 15:57 |
| uvos | but i cant retest now | 15:57 |
| uvos | since umts network is gohne in germany | 15:57 |
| tmlind | ok well i can't see any networks with my sim on bionic for some reason | 15:57 |
| uvos | also not gsm? | 15:58 |
| tmlind | not sure if i tried that, my us sim shows another operators network on 3g | 15:58 |
| Wizzup | well it's definitely reading the 128Mb flash | 16:03 |
| uvos | what 128mb flash? | 16:04 |
| Wizzup | don't know :) | 16:04 |
| Wizzup | I'll share the log in a sec | 16:04 |
| uvos | the lte modem on d4 has 128mb flash | 16:04 |
| uvos | but... | 16:04 |
| uvos | i gues the qcom modem might too | 16:04 |
| mighty17[m] | <tmlind> "mighty17: sorry i have really no..." <- oh ok, i'll ask xc racer | 16:06 |
| Wizzup | yes, it connected to my XS4ALL network :) | 16:06 |
| uvos | log usb packets & decompile sigmakey? | 16:07 |
| Wizzup | https://wizzup.org/sigmakey-d3-log.txt | 16:07 |
| Wizzup | uvos: yes, would be nice to do one day, but not this day :) | 16:08 |
| Wizzup | maybe when leste is my daily driver | 16:08 |
| buZz | 4droid4s even :P niiiice | 16:10 |
| uvos | looks like the qcom modem has a H8BCS0QG0MMR | 16:10 |
| buZz | 8 core mobile! | 16:10 |
| buZz | :D | 16:10 |
| The_Niz | :) | 16:11 |
| uvos | and android can clearly read it | 16:11 |
| uvos | sooo | 16:11 |
| uvos | hmm | 16:11 |
| Wizzup | uvos: yeah it requires a rooted device | 16:12 |
| uvos | the shit they hide in these things | 16:12 |
| Wizzup | I suspect it's a matter of reading certain info like IMEI and up front knowledge about how verizon does things for specific phones | 16:12 |
| uvos | (the phones) | 16:12 |
| Wizzup | and then they have a way to send that key, perhaps to the modem | 16:12 |
| Wizzup | there is an android gui to enter an unlock key | 16:13 |
| Wizzup | it did also write to the 'security area' so idk what it does exactly | 16:13 |
| Wizzup | but we can figure it out in the future since I have (counts...) 7 more | 16:13 |
| * tmlind probably owes another pint of beer | 16:13 | |
| tmlind | Wizzup: maybe also give it a try on your droid4 to see if it can dump out some info | 16:14 |
| Wizzup | I think the software advertises just changing the frequencies on the droid 4, but yeah, can try, I think it requires to be booted to android (of course) | 16:14 |
| Wizzup | (for the d4 specifically, wrt frequencies I mean) | 16:14 |
| tmlind | Wizzup: also, i posted a patch to add module options to phy-cpcap-mapphone to expose the mdm6600 to the pc usb port | 16:14 |
| uvos | neat | 16:15 |
| Wizzup | ah, cool, so one can run ofono on their pc | 16:15 |
| uvos | well the gpios wont work | 16:15 |
| uvos | but sure qmi only | 16:15 |
| Wizzup | right | 16:15 |
| tmlind | that's for reflashing the modem so two usb uart modes, that's probably what the sigmakey also needs | 16:16 |
| tmlind | https://lore.kernel.org/linux-usb/20181206155751.GE39861@atomide.com/ | 16:16 |
| tmlind | then there's another mode not yet implemented that just puts the booted modem to the usb port for pc for qmi | 16:17 |
| tmlind | i think it's just another variation of the mode gpios or something trivial like that | 16:17 |
| Wizzup | sigmakey did everything from adb as far as I can tell | 16:17 |
| tmlind | oh interesting | 16:17 |
| Wizzup | and it requires a rooted android, so it probably uploads software to it to read stuff | 16:18 |
| tmlind | maybe it did adb reboot bootloader to some modem service mode | 16:18 |
| Wizzup | no, the device was unlocked and then restarted | 16:18 |
| tmlind | hmm | 16:18 |
| Wizzup | once it did that it also lost the qemu usb, so there's no way it could do more | 16:18 |
| tmlind | from android the modem can be put into flash mode yeah | 16:20 |
| Wizzup | so what we can do is stuff all the adb traffic and also somehow try to intercept what sw it uploads to the device and strace it, but that'll be involved | 16:20 |
| Wizzup | s/stuff/sniff/ | 16:21 |
| Wizzup | but it also performs some calc on the pc itself afaik | 16:21 |
| Wizzup | in any case we can do this as often as we want for free now | 16:21 |
| uvos | at Wizzups house anyways | 16:22 |
| uvos | doing it remotely will also be involved | 16:22 |
| uvos | btw adb works over the network too | 16:22 |
| uvos | so if it really only uses adb | 16:22 |
| uvos | ... | 16:22 |
| tmlind | i think it's the update-binary that can be used to reconfigure mdm6600 for flash mode on android, it just uses the /sys entries for gpios to reboot the modme to flash mode | 16:22 |
| tmlind | the update-binary is there in the modem firmware blob | 16:23 |
| Wizzup | uvos: I think usbip should work, I will try that next | 16:23 |
| Wizzup | it was already confirmed to work on the android forums | 16:24 |
| Wizzup | tmlind: ah | 16:24 |
| Wizzup | uvos: actually qemu has usbredir so that's easier | 16:24 |
| Wizzup | can work with* | 16:25 |
| Wizzup | I remember doing that many years ago to forward a usb cd drive to my home from sofia | 16:25 |
| Wizzup | in any case the point was that this can be done networked | 16:25 |
| Wizzup | otherwise I wouldn't have gotten the damn dongle :p | 16:25 |
| uvos | "forward a usb cd drive to my home from sofia" lol | 16:26 |
| Wizzup | it was slow to rip but it worked :) | 16:26 |
| dgamer69 | I'm trying to get decent perfomance on my maemo leste qemu instance | 16:26 |
| dgamer69 | and I got reccomended accelerated grphics | 16:27 |
| Wizzup | dgamer69: it will be hard to get that unless you get ownership or your device I fear, if you don't have cpu accel then cpu 3d rendering will be even slower than normal | 16:27 |
| uvos | that sounds like the least sane way to rip a cd to some place over the network | 16:27 |
| uvos | but ok :P | 16:27 |
| Wizzup | uvos: yeah, well it was like this, I had this intel nuc at home with my sw, and my laptop with a cd drive in sofia | 16:27 |
| Wizzup | and I had to test ripping | 16:27 |
| Wizzup | only later I found cdemu which was slightly easier ;) | 16:27 |
| dgamer69 | :( | 16:28 |
| dgamer69 | nooooooooo | 16:28 |
| dgamer69 | https://github.com/knazarov/homebrew-qemu-virgl | 16:28 |
| Wizzup | you got that to work? | 16:28 |
| dgamer69 | not really | 16:28 |
| dgamer69 | I get this error: | 16:28 |
| uvos | maybe try with just the Hypervisor.framework patches | 16:29 |
| bencoh | I had a qemu/qxl setup working iirc | 16:29 |
| bencoh | lemme check | 16:29 |
| bencoh | haven't tried with leste though | 16:29 |
| dgamer69 | Couldn't open libEGL.dylib: dlopen(libEGL.dylib, 5): image not found | 16:29 |
| Wizzup | bencoh: the problem here is that he's on a mac he cannot root or install on what he wants | 16:29 |
| Wizzup | bencoh: so all normal ideas are out of the window | 16:29 |
| bencoh | oh, macosx | 16:29 |
| uvos | dgamer69: try without 3d accel | 16:29 |
| uvos | there is a Hypervisor.framework fork for qemu | 16:29 |
| dgamer69 | qemu works without 3d accel | 16:29 |
| uvos | somewhere | 16:29 |
| bencoh | I eventually stopped bothering with macosx a year ago | 16:29 |
| uvos | dgamer69: sure but you have not cpu accel either then | 16:30 |
| tmlind | Wizzup: the command to reflash mdm6600 is update-binary 3 1 radio.zip, you can repack radio.zip to leave out the w3glte firmware | 16:30 |
| uvos | dgamer69: since it needs patched qemu | 16:30 |
| dgamer69 | about a year ago I teid every display option, and they all worked | 16:30 |
| dgamer69 | I downloaded patched qemu from homebrew | 16:30 |
| dgamer69 | check the github page | 16:30 |
| uvos | you downloaded 3d accel patched qemu | 16:30 |
| dgamer69 | yeah | 16:30 |
| uvos | with also cpu accel patches | 16:30 |
| dgamer69 | I think so | 16:31 |
| dgamer69 | possibly? | 16:31 |
| uvos | but you need a version with just the cpu accell patches | 16:31 |
| dgamer69 | why? don't I want 3d acceleration as well? | 16:31 |
| uvos | because its not working | 16:31 |
| uvos | dlopen(libEGL.dylib, 5): image not found | 16:31 |
| dgamer69 | okay | 16:31 |
| uvos | just cpu accel wont run into that | 16:31 |
| uvos | and will be fast enoughish | 16:32 |
| dgamer69 | but I also want to try to run steam | 16:32 |
| uvos | well that wont work | 16:32 |
| uvos | and is out of scope here | 16:32 |
| dgamer69 | rip | 16:32 |
| dgamer69 | I'm trying to find a way | 16:32 |
| dgamer69 | regardless I'm curious | 16:32 |
| Wizzup | so it is out of scope, but also steam has a mac port doesn't it? | 16:32 |
| dgamer69 | so how do I get the patch? | 16:32 |
| dgamer69 | it does | 16:32 |
| Wizzup | If I were you I'd try to just root the device and get admin access | 16:32 |
| Wizzup | but yeah this is a bit off topic for this channel :p | 16:33 |
| dgamer69 | I am able to install steam using homebrew with no admin | 16:33 |
| dgamer69 | qemu channel is not responding lmao | 16:33 |
| dgamer69 | but whenI run steam, the steam servers are blocked | 16:36 |
| dgamer69 | and it gets stuck trying to update | 16:36 |
| uvos | they filterd the ip addresses | 16:37 |
| Wizzup | or dns | 16:37 |
| uvos | or maybe just the dns requests | 16:37 |
| dgamer69 | maybe | 16:37 |
| uvos | if they are dumb | 16:37 |
| dgamer69 | our school uses fortinet | 16:37 |
| Wizzup | maybe we need to re-instate the offtopic channel hehe | 16:38 |
| dgamer69 | lmao | 16:38 |
| dgamer69 | is there a way to route traffic on a per application basis without admin? | 16:38 |
| dgamer69 | I know tor does it | 16:38 |
| uvos | i dont think anyone here knows that mutch about macos | 16:39 |
| Wizzup | https://itectec.com/superuser/getting-steam-exe-to-run-through-a-http-proxy/ | 16:39 |
| Wizzup | just google, you'll find it | 16:39 |
| dgamer69 | that's for the exe | 16:39 |
| bencoh | I used to know quite a bit, but I didn't upgrade past osx.7 | 16:39 |
| dgamer69 | does that work on macos? | 16:40 |
| bencoh | so ... I doubt it would help :> | 16:40 |
| Wizzup | https://superuser.com/questions/387856/getting-steam-exe-to-run-through-a-http-proxy says it works on os x | 16:40 |
| Wizzup | but really just read/search before you ask pls ;) | 16:40 |
| dgamer69 | oh sorry | 16:40 |
| Wizzup | bencoh: I stopped at os 9 :p | 16:40 |
| dgamer69 | but thanks, I will try this | 16:40 |
| Wizzup | dgamer69: np | 16:40 |
| bencoh | Wizzup: oh, a Classic user! :) | 16:40 |
| Wizzup | yeah mostly 7.6.1 I think | 16:41 |
| uvos | uvos only ever used system 7 | 16:41 |
| bencoh | i went from system ~6 to osx.7, skipping a few updates here and there | 16:41 |
| Wizzup | I was basically a kid when I used system 7, and switched to windows at some point | 16:42 |
| bencoh | (funny to think that system6 is older than me) | 16:42 |
| dgamer69 | “steam_osx” is damaged and can’t be opened. You should move it to the Trash. | 16:44 |
| dgamer69 | why | 16:44 |
| dgamer69 | this is the worst | 16:44 |
| dgamer69 | nope I got it | 16:47 |
| Wizzup | tmlind: uvos said that you discovered something wrt droid4 memory timing not being entirely within what motorola specced, is that correct? | 16:50 |
| Wizzup | I had one or two droid 4 resets in the past ~3 weeks | 16:50 |
| Wizzup | every time pstore had nothing relevant | 16:51 |
| uvos | the memory interface registers get ajusted based on the opp. if that means that its out of spec on d4 after kexec remains tbd | 16:52 |
| uvos | unless tmlind as new information | 16:52 |
| uvos | and i was supposed to check the registers on bionic but forgot | 16:53 |
| uvos | i should go do that :P | 16:53 |
| tmlind | yeah so crank up the cpu frequency to full speed before kexec, so we should have the 1.2ghz timings in place for the new kernel | 16:54 |
| tmlind | still needs to be checked though | 16:55 |
| uvos | tmlind: in the mean time maybe push out new kexecboot that dose this | 16:55 |
| dgamer69 | hey does anyone know how to forward an application's traffic through a proxy without admin? | 16:56 |
| uvos | also please ajust it to use the max freq from sysfs instead of using 1.2ghz hardcoded | 16:56 |
| uvos | since rn that would fail on old mapphones like d3 | 16:56 |
| tmlind | uvos: we already do it, but we only do it for cpu1.. i think that should be enought though afaik they're coupled | 16:56 |
| tmlind | have not verified though | 16:56 |
| Wizzup | how would that work in clown boot scenarios where we have already kexec'd before getting to kexecboot? | 16:57 |
| uvos | Wizzup: the kexec scrippt | 16:57 |
| uvos | has to do it | 16:57 |
| Wizzup | dgamer69: there are various ways but I suggest looking at getting admin on your device instead | 16:57 |
| Wizzup | uvos: yeah ok so we do it in two places then | 16:57 |
| uvos | yeah | 16:57 |
| uvos | kexecboot doing it again on the mainlike kernel is not effective | 16:57 |
| dgamer69 | how would I even do that? the bootloader is locked so I can't boot into a different os | 16:57 |
| uvos | (or damaging) | 16:57 |
| tmlind | uvos: i made some kind of shell script to dump out all the android timings, depends on rwmem binary | 16:58 |
| uvos | tmlind: neat | 16:58 |
| uvos | where? :P | 16:58 |
| Wizzup | dgamer69: maybe just google around, I'm sure there are loads of people with a similar situation to yours | 16:58 |
| tmlind | uvos: i'll upload, i dropped the ball when i figured my mz609 has broken memory.. | 16:58 |
| uvos | ok | 16:59 |
| dgamer69 | how to get the admin password? | 16:59 |
| dgamer69 | I guess I'll look | 16:59 |
| uvos | great that your mz609 has broken memory, that means i have a better change of working mz617 :D | 16:59 |
| tmlind | yeh i want to use mz617 for topo maps with gps for fishing eventually :p | 17:00 |
| tmlind | hmm hopefully my script is not on the flakey mz609.. | 17:00 |
| uvos | if so its nbd | 17:01 |
| uvos | its not like its hard to check the registers with the register manual in one hand and rwmem in the other | 17:01 |
| uvos | id be courious if sgx also changes the state | 17:02 |
| uvos | since sgx is the main consumer of memory bandwith | 17:02 |
| uvos | that would make sense | 17:02 |
| tmlind | uvos: script updloaded to muru.com/linux/d4/d4-dump-emif-android.sh | 17:03 |
| uvos | tmlind: | 17:03 |
| uvos | ok | 17:03 |
| tmlind | uvos: it assumes rwmem is in /data/local/tmp/ | 17:03 |
| uvos | yeah | 17:03 |
| uvos | ill need to see if you can fix sgx clocks too | 17:03 |
| tmlind | when diffing values, you need to ignore timer regs in the emif | 17:04 |
| uvos | ok | 17:04 |
| tmlind | i'm pretty sure we already have 1.2ghz values for both emif1 and 2 but have not verified | 17:04 |
| tmlind | i patched kexecboot scripts to set the speed the same way as d4-dump-emif-android.sh, but not sure if that's really needed | 17:05 |
| uvos | cant hurt | 17:05 |
| uvos | meanwhile | 17:10 |
| uvos | hp detection works! | 17:10 |
| uvos | but pulse dosent switch | 17:10 |
| uvos | but i can see it in dmesg :) | 17:10 |
| Wizzup | sweet | 17:10 |
| tmlind | nice :) | 17:10 |
| Wizzup | uvos: does it also create an input device? | 17:14 |
| uvos | no something is wrong | 17:41 |
| uvos | i have a fn pointer set to .set_jack in snd_soc_component_driver | 17:42 |
| uvos | but it never gets called | 17:42 |
| uvos | so the jack isent registerd | 17:42 |
| uvos | im likely just missing something | 17:42 |
| bencoh | uvos: hp detection works? wait, so you reused that weird code from android's kernel? | 17:43 |
| uvos | no so right now im just assumeing if the what the irq means | 17:44 |
| bencoh | you use the irq as a toggle? | 17:44 |
| uvos | yeah but it looks like you can infer what way the jack is going via irq direction | 17:44 |
| uvos | i have to check that | 17:44 |
| bencoh | like rising/falling edge? | 17:44 |
| uvos | yeah | 17:44 |
| uvos | the wierd android code seams to only be needed if you want to know | 17:44 |
| bencoh | hmm | 17:44 |
| uvos | if the plug has a mic and buttons and so on | 17:44 |
| bencoh | sounds tricky, you should test booting with jack connected/disconnected | 17:45 |
| bencoh | to see it if inverts it | 17:45 |
| bencoh | if it* | 17:45 |
| uvos | yeah | 17:45 |
| bencoh | also there could be other events | 17:45 |
| uvos | yeah for sure | 17:45 |
| uvos | rn im still strugelling with asoc | 17:45 |
| bencoh | :) | 17:45 |
| uvos | in accutally getting the stuff out to userspace | 17:45 |
| dgamer69 | okay I'm back | 18:09 |
| dgamer69 | I've determined, with the bootloader locked, there is no good way to get the administrator password | 18:10 |
| dgamer69 | so now I'm curious | 18:10 |
| dgamer69 | is there a way to make a terminal instance with a keylogger? | 18:10 |
| Wizzup | this is a bit too off topic I think :) | 18:11 |
| dgamer69 | gotcha | 18:11 |
| dgamer69 | channel reccomendation? | 18:11 |
| Wizzup | not really | 18:18 |
| Wizzup | but keylogging your school machine to get an admin pw is def off topic here :p | 18:19 |
| dgamer69 | lmao | 18:20 |
| dgamer69 | alright | 18:20 |
| dgamer69 | thanks for all the help though! | 18:20 |
| buZz | why not buy a computer instead of being a thief | 18:21 |
| uvos | lets not get into this.... | 18:22 |
| dgamer69 | theif? | 18:25 |
| dgamer69 | I'm doing this for my friend who can't afford a gaming computer | 18:26 |
| dgamer69 | and how is this theft regardless | 18:26 |
| uvos | more wierdness | 18:35 |
| uvos | the cpcap register fires only when the cpcap headphone pga was turned on at least once | 18:36 |
| uvos | as you know you know cpcap turns off the pga when the jack is removed | 18:36 |
| uvos | and fires an itterupt | 18:36 |
| uvos | and then it fires again when its plugged | 18:36 |
| uvos | but if you disable the pga in kernel it dosent fire an itterupt | 18:36 |
| uvos | wth cpcap | 18:37 |
| uvos | looks like CPCAP_REG_INTS1 | 18:37 |
| uvos | (ie itterupt source riseing falling is stable not matter what at least) | 18:38 |
| Wizzup | getting there | 18:39 |
| Wizzup | hmmm so I updated my n900, and the ts is still weird (-devel) | 19:39 |
| Wizzup | everything maps to the top button | 19:39 |
| uvos | check xinput | 19:40 |
| Wizzup | what in particular? matrix? | 19:40 |
| Wizzup | Coordinate Transformation Matrix (156):0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 1.000000 | 19:41 |
| uvos | list-props in general | 19:41 |
| uvos | uh thats bad | 19:41 |
| Wizzup | the native orientation is landscape I think of this screen | 19:42 |
| uvos | yeah mulitplying everything with 0 will make the event allways be at 0 0 | 19:42 |
| uvos | what dose xinput map-to-output do? | 19:42 |
| uvos | set the Coordinate Transformation Matrix to the identiy matrix first | 19:42 |
| Wizzup | 1,0,0 0,1,0 0,0,1 | 19:45 |
| uvos | whats that? | 19:45 |
| uvos | when dose this appear | 19:45 |
| Wizzup | is that the identity you mean? | 19:46 |
| uvos | yeah ofc the 3x3 identity matrix | 19:46 |
| uvos | what you wrote is wrong | 19:47 |
| uvos | you have to manny 0 | 19:47 |
| uvos | no nvm | 19:47 |
| uvos | its correct | 19:47 |
| Wizzup | uvos: map to output does that | 20:10 |
| Wizzup | (as well) | 20:10 |
| buZz | hi Guest3 | 20:37 |
| Guest3 | Hey! You are doing interesting things! And when will the beta on the n900 be ready? I'm not a developer, just a user! | 20:43 |
| Wizzup | I think the beta is at least a few months out, probably jan 2021 or so? | 20:47 |
| Wizzup | I mean it's very much not set in stone, but for the n900 we need a few more things. (1) call audio routing (2) better power management, which relies on (3), (3) newer powervr driver | 20:48 |
| Wizzup | (1) I am working on now, (2) and (3) are more vague but progress has been made | 20:48 |
| Wizzup | and I think currently the n900 touch might be broken on all devices, so I have check what's up with that :) | 20:48 |
| Wizzup | uvos: regarding ^ any idea what could cause this? | 20:49 |
| Wizzup | Guest3: anyway it might still be too optimistic, we seem to hit problems everywhere we go, so everything takes time ;) | 20:50 |
| Wizzup | uvos: some libinput vs evdev thing maybe? | 20:51 |
| Guest3 | I wish you good luck guys! I've been following the project for a long time! I root for you very much! | 20:55 |
| Wizzup | :) | 20:56 |
| uvos | Wizzup: no | 21:04 |
| uvos | its proubly the omap ddx being broken | 21:04 |
| uvos | gimmy xrandr output | 21:04 |
| Wizzup | but it wasn't a problem with the rotation script | 21:04 |
| uvos | because we never installed the script on the n900 | 21:04 |
| Wizzup | ah. | 21:04 |
| Wizzup | # xrandr | 21:04 |
| Wizzup | Screen 0: minimum 800 x 480, current 800 x 480, maximum 800 x 480 | 21:04 |
| Wizzup | LCD connected primary (normal left inverted right x axis y axis) 800x480 6020.32 + | 21:04 |
| Wizzup | TV unknown connection (normal left inverted right x axis y axis) 800x480 6020.32 + 480x800 6020.32 | 21:05 |
| uvos | full output please | 21:05 |
| uvos | or is that it | 21:05 |
| Wizzup | that's it | 21:06 |
| uvos | Wizzup: time to step though https://github.com/maemo-leste/hildon-desktop/blob/1c3b31bca2ab0855f34af1e1a957cbb1cf06f125/src/util/hd-xinput.c#L287 then | 21:07 |
| uvos | or the equivalent in xinput | 21:07 |
| uvos | i would suspect this is wrong https://github.com/maemo-leste/hildon-desktop/blob/1c3b31bca2ab0855f34af1e1a957cbb1cf06f125/src/util/hd-xinput.c#L197 | 21:08 |
| uvos | i have had this problem with the omap ddx before | 21:08 |
| uvos | "I think the beta is at least a few months out, probably jan 2021 or so" heh | 21:22 |
| Wizzup | uvos: what do you think? :p | 21:30 |
| uvos | i think its october 2021 allready | 21:31 |
| uvos | but ymmv | 21:31 |
| uvos | i also think jan 2022 is optimistic | 21:32 |
| Wizzup | uvos: possible yeah | 21:33 |
| uvos | so plugg detection is with asoc-audio-graph-card is impossible | 21:43 |
| uvos | the only way it can work is if the plug is on a gpio see asoc_simple_init_jack | 21:44 |
| uvos | tmlind: ^^^^ | 21:44 |
| uvos | so haveing plugg detection based on just a cpcap interrupt and snd_soc_component_driver soc_codec_dev_cpcap.set_jack is only possible if we abandon the generic asoc-audio-graph-card and write a whole driver for cpcap-audio | 21:45 |
| uvos | also the generic asoc drivers are terribly documented (that is not documented at all) | 21:46 |
| uvos | so that royaly sucks | 21:46 |
| tmlind | heh | 22:02 |
| uvos | tmlind: any ideas? | 22:03 |
| tmlind | uvos: keep top level asoc driver generic, add more generic or custom child devices to it? | 22:04 |
| tmlind | that's what might help with the voice calls | 22:04 |
| tmlind | as linux knows nothing about it really | 22:04 |
| tmlind | we don't have cpcap-gpio driver as we have not needed it, but i guess it could set that up as another gpio? | 22:05 |
| uvos | tmlind: not sure how to approch that | 22:05 |
| uvos | let me explain the current dilemma: | 22:05 |
| uvos | so i want to snd_soc_jack_report in the cpcap codec in the lower half of the threaded interupt, so i need a snd_soc_jack and i need to register it with the frame work | 22:07 |
| uvos | so far so good | 22:07 |
| uvos | so i need to asoc_simple_init_jack for wich i need to snd_soc_card. snd_soc_card is asoc-audio-graph-card for us. | 22:11 |
| uvos | other drivers like all the sound/soc/intel deal with this by creating a jack and calling set_jack on the codecs snd_soc_component_driver with this jack | 22:12 |
| uvos | the codec then uses this jack to report its plug state | 22:12 |
| uvos | but since asoc-audio-graph-card dosent do this im in bind | 22:13 |
| uvos | i could go a head and create another snd_soc_card just to report the jack | 22:13 |
| uvos | but then pulse would not know where to apply the route to | 22:13 |
| uvos | so i really dont see any way forward other than to fork asoc-audio-graph-card to call set_jack on its componants | 22:15 |
| tmlind | uvos: yeah i don't know about that stuff, maybe send an email to kuninori morimoto asking how it should be handled with audio-graph-card? | 22:15 |
| uvos | but that becomes really messy | 22:15 |
| tmlind | right.. | 22:15 |
| uvos | because it shares all the componant handling with snd-soc-simple-card | 22:16 |
| uvos | so i would also have to fork snd-soc-simple-card-utils with it | 22:16 |
| uvos | not great | 22:16 |
| tmlind | yup | 22:16 |
| tmlind | so before heading for a custom codec driver, the voice call stuff we should be able to deal with a separate child device | 22:17 |
| tmlind | right now the voice call codec is a child of mcbsp, while it really should be a child of the cpcap audio driver | 22:18 |
| uvos | yeah | 22:18 |
| tmlind | that should solve the voice mixer issues | 22:18 |
| uvos | i helps when it dosent get powerd off when there is no audio on mcbsp | 22:18 |
| tmlind | yeah and if we want to add voice recording, we add something else that is a child of mcbsp and listens on the traffic | 22:19 |
| tmlind | so is there some gpio specified for the audio-graph-card binding for set_jack? | 22:20 |
| uvos | simple-card-utils grabs a gpio via of_get_named_gpio_flags for a jack, snd_soc_component_driver.set_jack just gives you a jack to report on see what the rt711 driver and codec do | 22:23 |
| tmlind | maybe export a notifier function from audio-graph-card that the codec can call? | 22:24 |
| uvos | i gues but that seams like reimplmenting what set_jack seams to be for anywhays | 22:26 |
| uvos | also i was hoping to not add api to audio-graph-card | 22:26 |
| tmlind | heh | 22:26 |
| uvos | considering my merge sucess so far | 22:26 |
| tmlind | uvos: so if you need to call set_jack from audio-graph-card, you need to provide something for the codec to use too? | 22:28 |
| tmlind | sounds like set_jack would be a nice generic feature to add.. | 22:29 |
| uvos | hmm not sure if i understand, if audio-graph-card called set_jack on the codec | 22:29 |
| uvos | the rest would just be in the codec | 22:29 |
| tmlind | i guess i don't follow where you need to call set_jack from.. | 22:30 |
| uvos | as it would just call snd_soc_jack_report on the jack it got | 22:30 |
| uvos | from the codec | 22:30 |
| uvos | the codec owns the jack | 22:30 |
| tmlind | ok | 22:30 |
| uvos | er from the card | 22:30 |
| uvos | i mean | 22:30 |
| uvos | the card ie audio-graph-card owns a jack | 22:30 |
| tmlind | ok | 22:30 |
| uvos | and we need the jack in the codec | 22:30 |
| uvos | and set_jack gives the codec a jack to use | 22:30 |
| uvos | but audio-graph-card dosent use it | 22:31 |
| tmlind | maybe you can add something to find jack | 22:31 |
| uvos | there is no api in the snd_soc framework to get a previously registerd jack from a snd_soc_card | 22:37 |
| uvos | so no dosent look like thats possible | 22:37 |
| uvos | with out going and pulling it via private api :P | 22:37 |
| tmlind | yeah kuninori morimoto might have some good ideas there though | 22:41 |
| tmlind | sleepy time here now, ttyl | 22:44 |
| uvos | ttyl | 22:58 |
| Wizzup | uvos: is this new h-d already in non-devel btw? | 23:00 |
| Wizzup | (with the touch screen problems on the n900) | 23:00 |
| uvos | Wizzup: no | 23:02 |
| uvos | did you stepp it with gdb | 23:03 |
| uvos | im pretty sure omap ddx's flaky reporting of the display size is the problem | 23:03 |
| uvos | either way there is likely something wrong on the n900 side consierding xinput is broken too | 23:04 |
| Wizzup | do you mean map-to-output? | 23:09 |
| Wizzup | yeah | 23:09 |
| uvos | yeah | 23:09 |
| uvos | step through xinput map-to-output with gdb especcaly what happens in set_transformation_matrix | 23:10 |
| uvos | that function i just copyed from xinput | 23:10 |
| uvos | and clearly the parameters it calculates are just 0 | 23:10 |
| uvos | so some input must be 0 too | 23:10 |
| uvos | you can also trace hildon if you like instead | 23:11 |
| uvos | dosent matter same code | 23:11 |
| Wizzup | I'll file a bug report and look at later, there's too much going on :) | 23:15 |
| uvos | well its pretty severly broken | 23:15 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/577 (N900 touchscreen is broken with latest -devel hildon-desktop) | 23:16 |
| uvos | maybe its the wrong crtc | 23:18 |
| uvos | could you try different values for crtc in --map-to-output $(TSDEVCIE) $(crtc) | 23:19 |
| uvos | i mean it clames that LCD is the "connected primary" | 23:20 |
| uvos | so that would be a bug in and of itself | 23:20 |
| uvos | but still | 23:20 |
| Wizzup | how do I get a list of the crtcs? | 23:22 |
| Wizzup | ah, --verbose | 23:22 |
| Wizzup | there is only one crtc it seems | 23:22 |
| Wizzup | uvos: how do I trigger h-d to recalc the matrix | 23:26 |
| Wizzup | (i.e. so I can break and analyse) | 23:26 |
| uvos | you cant | 23:26 |
| uvos | you have to start it in gdb | 23:26 |
| uvos | it runs it on starup once | 23:26 |
| Wizzup | looks like it happens right away when I press the power button | 23:26 |
| Wizzup | lol | 23:26 |
| uvos | oh ok | 23:26 |
| uvos | hmm | 23:26 |
| uvos | oh right h-d reregisters the xinput devices | 23:27 |
| uvos | so that they have a chance to close to save power | 23:27 |
| uvos | yeah thats right/fine | 23:27 |
| Wizzup | (gdb) print crtc_info->x | 23:33 |
| Wizzup | $1 = 0 | 23:33 |
| Wizzup | (gdb) print crtc_info->y | 23:33 |
| Wizzup | $2 = 0 | 23:33 |
| Wizzup | (gdb) print crtc_info->width | 23:33 |
| Wizzup | $3 = 0 | 23:33 |
| Wizzup | height is empty too | 23:33 |
| uvos | great | 23:34 |
| uvos | what is in output_info? | 23:34 |
| uvos | output_info.name should be interesting | 23:35 |
| Wizzup | (gdb) print output_info->name | 23:37 |
| Wizzup | $6 = 0x7101b8 "LCD" | 23:37 |
| uvos | ok | 23:37 |
| uvos | yeah looks broken | 23:37 |
| uvos | on xorgs side | 23:37 |
| Wizzup | int width = DisplayWidth(dpy, DefaultScreen(dpy)); int height = DisplayHeight(dpy, DefaultScreen(dpy)); | 23:38 |
| Wizzup | these are fine though | 23:38 |
| Wizzup | 198in hd-xinput.c | 23:38 |
| Wizzup | (gdb) print width | 23:38 |
| Wizzup | $9 = 800 | 23:38 |
| Wizzup | yeah so this becomes zero because of 0 / whatever: https://github.com/maemo-leste/hildon-desktop/blob/1c3b31bca2ab0855f34af1e1a957cbb1cf06f125/src/util/hd-xinput.c#L207 | 23:39 |
| uvos | yeah | 23:39 |
| Wizzup | so we have to fix the ddx, or have the code treat the screen size being 0 separately ;) | 23:40 |
| Wizzup | *cough* | 23:40 |
| uvos | check what output_info->crtc struct RRCrtc contains | 23:41 |
| uvos | maybe | 23:41 |
| uvos | but grasping at straws | 23:41 |
| uvos | but yes looks like ddx is broken | 23:42 |
| uvos | dose n900 share the same ddx as d4? | 23:42 |
| uvos | i thought it did | 23:42 |
| uvos | so its a bit wierd that it works ok on d4 | 23:42 |
| uvos | yeah we could sanity check the matrix | 23:43 |
| uvos | and not apply anyhting if its not sane | 23:43 |
| uvos | (ie some axis is 0) | 23:43 |
| uvos | time for sleeping, ttyl | 23:46 |
| Wizzup | (gdb) print output_info->crtc | 23:47 |
| Wizzup | $13 = 66 | 23:47 |
| Wizzup | hrm | 23:47 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
