| Wizzup | uvos: no, the "Help I'm alive" does not show either | 00:04 |
|---|---|---|
| uvos | hmm | 00:04 |
| uvos | that suggests that there is something wrong with the modules | 00:04 |
| Wizzup | I replaced uart.ko with your version | 00:04 |
| Wizzup | maybe that wasn't ok? | 00:04 |
| uvos | no ofc | 00:04 |
| uvos | you should load all modules as in the tar above | 00:04 |
| Wizzup | hm? | 00:04 |
| Wizzup | I replaced all of them | 00:04 |
| uvos | and none of the safestrap ones | 00:04 |
| uvos | ok | 00:05 |
| Wizzup | but yours was not called uart.ko, so I renamed it | 00:05 |
| uvos | yeah thats just how the build system works on the 2.6x branch | 00:05 |
| uvos | just geussing maybe there is some issue with compieling the module with a different gcc version that the kernel itself | 00:05 |
| Wizzup | it does print stuff, at various times, though | 00:06 |
| uvos | sutch as? | 00:06 |
| Wizzup | well, the noise | 00:06 |
| uvos | right | 00:07 |
| uvos | can you try to load the old uart .ko? | 00:07 |
| Wizzup | sure | 00:07 |
| Wizzup | now I do see serial messages | 00:09 |
| Wizzup | ABE[ 0.000000] Booting Linux on physical CPU 0x0 | 00:09 |
| uvos | woooo | 00:09 |
| Wizzup | [ 0.000000] printk: bootconsole [omap8250] enabled | 00:09 |
| uvos | its booting | 00:09 |
| Wizzup | that's the last msg I see | 00:09 |
| uvos | uh | 00:09 |
| Wizzup | https://pastebin.com/AF80P0EW | 00:09 |
| Wizzup | so maybe the serial is different? | 00:11 |
| uvos | so whats your kernel cmdline? | 00:11 |
| Wizzup | it's literally taken from the bionic boot.cfg, with one thing added: earlyprintk | 00:11 |
| uvos | Wizzup: could be also maybe the multiplexing workd sifferently | 00:11 |
| Wizzup | one sec | 00:11 |
| Wizzup | uvos: oh lol | 00:12 |
| Wizzup | I think it's this: | 00:12 |
| Wizzup | console=tty0 debug earlycon ro rootwait rootfstype=ext4 root=/dev/mmcblk0p2 | 00:12 |
| uvos | yeah ok | 00:12 |
| Wizzup | console=tty0 | 00:12 |
| uvos | well you should avoid disableing serial outpu :P | 00:12 |
| Wizzup | console=ttyS2,115200 then? | 00:12 |
| uvos | yeah | 00:12 |
| Wizzup | ok | 00:12 |
| Wizzup | one sec | 00:12 |
| uvos | anyhow [ 0.000000] OF: fdt: Machine model: Motorola Droid 3 XT862 is alllready a nice milestone :) | 00:13 |
| Wizzup | oh actually I did have the console in the cmdline | 00:14 |
| Wizzup | it is thi satm | 00:14 |
| Wizzup | /kexec -l /kernel --dtb=/devtree --command-line="console=tty0 console=ttyS2,115200 debug earlycon ro rootwait rootfstype=ext4 root=/dev/mmcblk0p2 softlevel=shell earlyprintk" | 00:14 |
| uvos | ok | 00:14 |
| uvos | hmm :| | 00:15 |
| Wizzup | let me take out console=tty0 | 00:15 |
| Wizzup | and softlevel=shell | 00:15 |
| Wizzup | same thing | 00:17 |
| Wizzup | maybe I should try the non-static bionic kernel, just in case my system miscompiles or something | 00:18 |
| Wizzup | (seems unlikely but hey) | 00:18 |
| uvos | sure i mean that should be quick to do | 00:19 |
| Wizzup | yeah | 00:19 |
| Wizzup | yeah... | 00:20 |
| Wizzup | gets further. | 00:20 |
| uvos | wierd | 00:20 |
| Wizzup | [ 1.414611] 8<--- cut here --- | 00:20 |
| Wizzup | [ 1.414642] ------------[ cut here ]------------ | 00:20 |
| Wizzup | [ 1.417755] Unhandled fault: imprecise external abort (0x1406) at 0xd3eef09d | 00:20 |
| Wizzup | [ 1.422515] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x228/0x374 | 00:20 |
| Wizzup | [ 1.429748] pgd = (ptrval) | 00:20 |
| Wizzup | [ 1.439147] 44000000.ocp:L3 Standard Error: MASTER MPU TARGET AES2 (Read Link): At Address: 0x00101080 : Data Access in User mode during Functional access | 00:20 |
| uvos | oh ok | 00:20 |
| uvos | we had that before | 00:20 |
| uvos | some omap co-processor is not in reset after kexec | 00:21 |
| Wizzup | https://pastebin.com/raw/S14QHSkH | 00:21 |
| uvos | and the android firmware messes with the kernel | 00:21 |
| Wizzup | hm | 00:22 |
| uvos | where are you kexecing from? | 00:22 |
| Wizzup | safestrap | 00:22 |
| Wizzup | I can try to do clownboot tomorrow if you think that makes more sense | 00:22 |
| uvos | only in the vaguest maybe sense | 00:23 |
| uvos | i think it makes more sense to try and parse the kernel ops | 00:23 |
| Wizzup | ops=oops? | 00:24 |
| uvos | yeah *oops | 00:24 |
| Wizzup | I suppose since this is our general bionic kernel we should have the debug symbols | 00:25 |
| Wizzup | for addr2line and such | 00:25 |
| uvos | yeah | 00:25 |
| uvos | anyhow good night | 00:27 |
| Wizzup | yeah, thank you! | 00:27 |
| uvos | yw | 00:27 |
| Wizzup | maybe it's memory setup | 00:36 |
| Wizzup | tmlind: if you have any ideas, btw: 00:21 < Wizzup> https://pastebin.com/raw/S14QHSkH | 00:45 |
| * Wizzup now also zzz | 00:45 | |
| tmlind | Wizzup: oh cool, you got it booting :) looks like aes2 is not accessible on those devices, try setting: | 06:17 |
| tmlind | &aes2_target { | 06:17 |
| tmlind | status = "disabled"; | 06:18 |
| tmlind | }; | 06:18 |
| Wizzup | tmlind: thanks, will do | 09:20 |
| Wizzup | tmlind: INIT: version 2.93 booting | 09:26 |
| Wizzup | :-) | 09:26 |
| Wizzup | https://pastebin.com/raw/8gydpDZP | 09:28 |
| Wizzup | waiting for a bit got me to inittab | 09:30 |
| Wizzup | er, serial | 09:30 |
| Wizzup | (tty) | 09:30 |
| Wizzup | wireless seems to work | 09:31 |
| Wizzup | usbnet works | 09:33 |
| Wizzup | display not working mihgt relate to this, perhaps? | 09:34 |
| Wizzup | Jul 23 09:28:49 localhost kernel: [ 3.340942] abe_cm:clk:0028:0: failed to enable | 09:34 |
| Wizzup | Jul 23 09:28:49 localhost kernel: [ 3.340942] ti-sysc: probe of 4012208c.target-module failed with error -16 | 09:34 |
| Wizzup | Jul 23 09:28:49 localhost kernel: [ 3.363189] clk: failed to reparent abe_cm:clk:0060:24 to sys_clkin_ck: -22 | 09:34 |
| Wizzup | later on also: | 09:34 |
| Wizzup | Jul 23 09:28:49 localhost kernel: [ 7.583190] abe_cm:clk:0030:0: failed to enable | 09:34 |
| Wizzup | Jul 23 09:28:49 localhost kernel: [ 7.827301] lm75: probe of 0-0048 failed with error -121 | 09:35 |
| uvos | Wizzup: sweet looks like mosty everything works :) | 10:37 |
| uvos | i would not worry about the omap_vc_calc_vsel: voltage not supported by pmic: 1375000 vs max 1350000 i had that on bionic too its just the bootloader starting the device with higher voltage than d4/bionic and so higher than the kernel expects moto likely gained confidence in the silicon over time and reduced the voltage in stepps | 10:39 |
| uvos | i have no idea on the dsi, really | 10:40 |
| uvos | other than to, again, compear the stock kernel between d3 and bionic | 10:40 |
| Wizzup | ok | 11:07 |
| tmlind | Wizzup: great, you need to look at the dtb blob and get the timing values for the panel and figure out if it's a dsi command mode panel or a regular dsi panel | 11:46 |
| tmlind | the motorola dtb is non-standard endian, just look at it with a hex editor and compare to droid4 and bionic | 11:47 |
| tmlind | the property to look at is probably named Display@0 | 11:48 |
| tmlind | hmm actually it's easier to get the info from the stock kernel dmesg | 11:49 |
| tmlind | and then you need to configure the backlight controller | 11:50 |
| tmlind | maybe post the stock kernel dmesg output somewhere to look at? | 11:55 |
| tmlind | bbl | 11:55 |
| Wizzup | tmlind: ok, ty | 12:14 |
| Wizzup | will do | 12:14 |
| Wizzup | tmlind: here is dmesg https://pastebin.com/raw/3fvEQ1fP | 13:31 |
| Wizzup | that is dmesg from safestrap | 13:31 |
| uvos | hmm | 13:42 |
| uvos | its missing board_panel | 13:42 |
| uvos | could you do from android | 13:43 |
| uvos | Wizzup: also it looks like backing off 2mb is not nessecary on d3 | 13:43 |
| uvos | oh its just formated different on the older kernel | 13:44 |
| uvos | <6>[ 1.768554] DT: x_res=540 y_res=960 phy_w_mm=50 phy_h_mm=89 | 13:44 |
| uvos | <6>[ 1.768585] DT: hfp=0 hsw=2 hbp=2 vfp=0 vsw=1 vbp=1 | 13:44 |
| uvos | <6>[ 1.768585] DT: clk_lane=1 clk_pos=1 d1_lane=2 d1_pos=1 | 13:44 |
| uvos | <6>[ 1.768585] DT: d2_lane= 3 d2_pos= 1 xfer_mode= 0 | 13:44 |
| uvos | <6>[ 1.768615] DT: panel_id=0x90004 | 13:44 |
| uvos | <6>[ 1.768615] DT: regn=13 regm=230 regm3=7 regm4=7 lp_clk_div=8 lck_div=1 pck_div=4 | 13:44 |
| uvos | <6>[ 1.778472] Mapphone panel: controller supplier id(A1h)=0x10b | 13:44 |
| uvos | <6>[ 1.778503] Mapphone panel: panel manufacturer ID (DAh)=0x1 | 13:44 |
| uvos | <6>[ 1.778533] Mapphone panel: controller version (DBh)=0x1 | 13:44 |
| uvos | <6>[ 1.778594] Mapphone panel: controller driver ID(DCh)=0x2 | 13:44 |
| uvos | looks the same as d4 | 13:45 |
| uvos | which makes sense | 13:45 |
| uvos | the pannel has the same part number printed on it | 13:45 |
| uvos | ah no its subtaly different | 13:47 |
| uvos | clk_pos=0 vs clk_pos=1 | 13:47 |
| uvos | timeings (back front portch etc) are the same | 13:51 |
| uvos | not sure what clk_pos is | 13:51 |
| uvos | datasheet time i gues | 13:51 |
| Wizzup | uvos: still need it from android? | 13:55 |
| uvos | Wizzup: no | 13:55 |
| Wizzup | ok | 13:55 |
| uvos | has something to do with port {} in dts i gues | 13:55 |
| uvos | clk_lane and d1 lane and so on are different | 13:55 |
| uvos | so the lcd is the same lcd | 13:56 |
| uvos | connected to different pins | 13:56 |
| Wizzup | same panel id? | 13:56 |
| uvos | iiuc | 13:56 |
| uvos | yeah that too | 13:56 |
| uvos | bu also same timeings etc | 13:56 |
| uvos | should not be to hard to figure out how to set it by reading the dts binding documentation and omap datasheet | 13:57 |
| uvos | but maybe tmlind just knows | 13:58 |
| Wizzup | hm, where do the bionic lcd panel timings come from, also motorola-mapphone-common.dsti? | 13:59 |
| uvos | yeah its dsi1 | 13:59 |
| uvos | in that file | 13:59 |
| uvos | the part we are worryed about is port { | 13:59 |
| uvos | the stuff in lcd0: panel@0 { looks like its the same between d4 and d3 | 14:00 |
| Wizzup | ok | 14:01 |
| uvos | at least if im reading this correctly | 14:02 |
| Wizzup | recommendation for hex editor? I usually use xxd | 14:03 |
| uvos | i use okteta | 14:04 |
| uvos | but i mean any should do | 14:04 |
| Wizzup | this is the stock dtb: https://wizzup.org/d3_device_tree.bin | 14:05 |
| uvos | can you still boot 3.0 ? | 14:06 |
| uvos | the 2.6 kernel dosent print some stuff | 14:06 |
| uvos | like dsi_vc_cmd | 14:07 |
| uvos | wich i assume tells us if the fw of the lcd is configured for video mode or not | 14:07 |
| Wizzup | ok, yeah, I can install safestrap 3.x in a bit | 14:08 |
| Wizzup | xxd doesn't make much sense of that device tree as is | 14:08 |
| uvos | the data for the display is at 0x250 | 14:10 |
| uvos | but dont ask me how to interpret it | 14:11 |
| Wizzup | Let me see if I can pull in okteta without the entirety of kde | 14:15 |
| Wizzup | (nope) | 14:24 |
| uvos | bless then? | 14:25 |
| Wizzup | trying wxhexeditor atm | 14:26 |
| Wizzup | lol it writes "Rahman ve Rahim olan Allah'ın adıyla." on exit | 14:30 |
| Wizzup | ok | 14:30 |
| Wizzup | yeah so it looks like the dtc opcodes are the opposite endianness, but the strings are not, obviously | 16:07 |
| uvos | hi | 16:31 |
| uvos | Wizzup: did you get anywhere in my absense | 16:31 |
| uvos | i dont think you accutally need to decompile the dtb | 16:32 |
| uvos | you just have to figure out how d1_pos .. dn_pos mapps to mainline dts | 16:33 |
| Wizzup | uvos: I'm having trouble reading the dtb properly, did you see the one I uplodaed? | 16:33 |
| uvos | sure but that would not help us that much anyhow | 16:34 |
| uvos | it contains the same info | 16:34 |
| uvos | and then we still dont know how the bindings work for mainline | 16:34 |
| Wizzup | ok | 16:34 |
| uvos | just look at the mainline dts binding doucmentation | 16:34 |
| Wizzup | let me make a coffee first | 16:35 |
| Wizzup | btw, it would still be good see if we can find the dts patch somewhere | 16:36 |
| uvos | i suspect d1...d5 that is the only difference between d4 and d3 corrisponds to lanes = <0 1 2 3 4 5>; | 16:36 |
| uvos | somehow | 16:36 |
| Wizzup | there might be more devices where we want this | 16:36 |
| uvos | but thats just my guess | 16:36 |
| Wizzup | uvos: yeah I also saw the lanes in dmesg | 16:36 |
| uvos | Wizzup: sure @patch | 16:37 |
| uvos | i want to do xt910 at some point | 16:38 |
| uvos | so yeah | 16:38 |
| uvos | the lcd data lines are liekly connected differently due to board space conciderations. for the the d3 they where still saveing space by haveing the kayboard and sensors on own super thin flex pcbs, while the d4 is a cost reduced design where there is only 1 pcb with everything. as a side effect they had more space for routing traces | 17:00 |
| uvos | thats also why the d4 is so mutch thicker than d1-3 | 17:01 |
| Wizzup | mhm | 17:05 |
| Wizzup | uvos: so you're asking what the lanes = < ... > are exactly, and would like me to see if I can find that in the device-tree doc ? | 17:06 |
| uvos | yeah | 17:06 |
| Wizzup | grepping for lanes should indeed different orders (say in 950 dts) | 17:11 |
| Wizzup | not quite sure where I can find the dsi port/lanes info yet (grepping my way around Documentation/device-tree) | 17:12 |
| Wizzup | it looks like the panel doc is display/panel/panel-dsi-cm.yaml - but it doesn't mention the port | 17:15 |
| Wizzup | maybe ./display/ti/ti,omap4-dss.txt ? | 17:17 |
| Wizzup | DSI Endpoint required properties: | 17:17 |
| Wizzup | - lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, DATA1+, DATA1-, ... | 17:17 |
| Wizzup | uvos: ^^ ? | 17:17 |
| Wizzup | uvos: I mean assuming that clk_lane = 1 means that the clock is the first, then data0, then data1 the regular order might make sense? | 17:20 |
| Wizzup | not sure what the '*_pos=1' means | 17:21 |
| uvos | Wizzup: clk_lane on d4 i s0 | 17:23 |
| uvos | *Wizzup: clk_lane on d4 is 0 | 17:23 |
| Wizzup | as opposed to 1, you mean? | 17:23 |
| uvos | yeah | 17:23 |
| uvos | sec | 17:23 |
| Wizzup | the thing is that the <lanes> mentions pos and neg | 17:23 |
| Wizzup | but the dmesg talks about 3 lanes only | 17:23 |
| uvos | so dose dmseg | 17:23 |
| uvos | clk_pos is clk+ | 17:24 |
| Wizzup | so I figured the _pos=1 means os comes first or something | 17:24 |
| Wizzup | <6>[ 1.768585] DT: clk_lane=1 clk_pos=1 d1_lane=2 d1_pos=1 | 17:24 |
| Wizzup | <6>[ 1.768585] DT: d2_lane= 3 d2_pos= 1 xfer_mode= 0 | 17:24 |
| uvos | and lane is clk - | 17:24 |
| uvos | but the number is the same | 17:24 |
| uvos | so thats wierd | 17:24 |
| Wizzup | I think all the _pos=1 | 17:24 |
| uvos | let me boot los on d4 again sec | 17:24 |
| uvos | maybe that means +1 | 17:24 |
| uvos | but no ida | 17:24 |
| uvos | idea | 17:24 |
| Wizzup | yes, it could be either :p | 17:24 |
| uvos | [ 0.201080,0] board_panel: DT: phy.dsi: data1_lane=2 data1_pol=0 | 17:27 |
| uvos | [ 0.201110,0] board_panel: DT: phy.dsi: data2_lane=3 data2_pol=0 | 17:27 |
| uvos | [ 5.275909,0] DT: clk_lane=1 clk_pos=0 d1_lane=2 d1_pos=0 d2_lane=3 d2_pos=0 | 17:28 |
| uvos | [ 5.276062,0] DT: d3_lane=0 d3_pos=0 d4_lane=0 d4_pos=0 | 17:28 |
| uvos | [ 5.276153,0] DT: panel_id=0x90004 type= 0 | 17:28 |
| uvos | so for starters d1_lane is 2 | 17:28 |
| uvos | but then it dosent make any sense | 17:29 |
| uvos | since d4 and and d3 is 0 | 17:29 |
| uvos | so it cant mapp to data0+-/data1+- in any sane way | 17:29 |
| uvos | here is d4's entier print on the lcd for referance: | 17:30 |
| uvos | [ 0.201049,0] board_panel: DT: width= 540 height= 960 | 17:30 |
| uvos | [ 0.201049,0] board_panel: DT: hfp=0 hsw=2 hbp=2 vfp=0 vsw=1 vbp=1 | 17:30 |
| uvos | [ 0.201080,0] board_panel: DT: gpio_reset=101 panel_id=0x90004 | 17:30 |
| uvos | [ 0.201080,0] board_panel: DT: phy.dsi: pixel_size=24 te_scan_line=300 | 17:30 |
| uvos | [ 0.201080,0] board_panel: DT: phy.dsi: data1_lane=2 data1_pol=0 | 17:30 |
| uvos | [ 0.201110,0] board_panel: DT: phy.dsi: data2_lane=3 data2_pol=0 | 17:30 |
| uvos | [ 0.201110,0] board_panel: DT: clocks.dsi : regn=13 regm=230 | 17:30 |
| uvos | [ 0.201110,0] board_panel: DT: clocks.dsi : regm3=6 regm4=6 | 17:30 |
| uvos | [ 0.201141,0] board_panel: DT: clocks.dsi : lp_clk_div=9, lck_div=1, pck_div=4 | 17:30 |
| uvos | [ 0.201141,0] board_panel: DT: phy.dsi.type=0 | 17:31 |
| Wizzup | _pos here are all 0 instead of 1, it looks like | 17:31 |
| uvos | [ 5.275634,0] DSI: dsi_vc_cmd = 0, dsi_vc_video = 1 | 17:31 |
| uvos | [ 5.275695,0] DT: x_res=540 y_res=960 phy_w_mm=50 phy_h_mm=89 | 17:31 |
| uvos | [ 5.275848,0] DT: hfp=0 hsw=2 hbp=2 vfp=0 vsw=1 vbp=1 | 17:31 |
| uvos | [ 5.275909,0] DT: clk_lane=1 clk_pos=0 d1_lane=2 d1_pos=0 d2_lane=3 d2_pos=0 | 17:31 |
| uvos | [ 5.276062,0] DT: d3_lane=0 d3_pos=0 d4_lane=0 d4_pos=0 | 17:31 |
| uvos | [ 5.276153,0] DT: panel_id=0x90004 type= 0 | 17:31 |
| uvos | [ 5.276275,0] DT: regn=13 regm=230 regm3=6 regm4=6 lp_clk_div=9 lck_div=1 pck_div=4 | 17:31 |
| uvos | [ 5.276367,0] DT: te_support=1, te_type=0 | 17:31 |
| uvos | [ 5.276489,0] DT: number of power supplies=1 | 17:31 |
| uvos | [ 5.276580,0] DT: Supply #0, reg name=sw5, gpio=96, gpio_en_val=1 | 17:31 |
| uvos | [ 5.295471,0] Mapphone panel: controller supplier id(A1h)=0x10b | 17:31 |
| uvos | [ 5.295562,0] Mapphone panel: panel manufacturer ID (DAh)=0x1 | 17:31 |
| uvos | [ 5.295745,0] Mapphone panel: controller version (DBh)=0x1 | 17:31 |
| uvos | [ 5.295837,0] Mapphone panel: controller driver ID(DCh)=0x2 | 17:31 |
| uvos | yeah | 17:31 |
| Wizzup | so maybe something like <1 0 3 2 5 4> could work? | 17:31 |
| uvos | maybe | 17:31 |
| Wizzup | (assuming pos just means if it comes first or not) | 17:31 |
| uvos | its clear that clk_lane and d*_lane corrispond to the CLK+, CLK-, DATA0+, DATA0-, DATA1+, DATA1- somehow | 17:32 |
| Wizzup | kernel driver could maybe tell us | 17:32 |
| uvos | but yeah | 17:32 |
| uvos | Wizzup: wich one? | 17:32 |
| Wizzup | https://github.com/STS-Dev-Team/kernel_kexec_modules/blob/5f4220efe52185f602ccd7496f01a0b1c66ef95d/drivers/video/omap2/displays/panel-mapphone.c#L963 ? | 17:33 |
| Wizzup | so pos is the polarity? | 17:33 |
| Wizzup | (data1_pol) | 17:33 |
| uvos | that makes sense yeah | 17:33 |
| Wizzup | what confuses me here a bit is how one could have clk+ ,data0-, etc in this schema | 17:34 |
| uvos | but to flip the polarity fliping data*+ and data*- in mainline kernel should work | 17:34 |
| Wizzup | maybe nobody does it for some EE reason | 17:34 |
| Wizzup | uvos: yes | 17:34 |
| uvos | so flip every 2 values where pol is different from d4 and try it? | 17:34 |
| Wizzup | well, that is everywhere, no? | 17:35 |
| Wizzup | (if I read correctly) | 17:35 |
| uvos | looks like | 17:35 |
| uvos | yeah | 17:35 |
| Wizzup | so that would be: | 17:35 |
| Wizzup | 17:31 < Wizzup> so maybe something like <1 0 3 2 5 4> could work? | 17:35 |
| uvos | yes | 17:35 |
| uvos | brb | 17:36 |
| Wizzup | uvos: ;-) | 17:45 |
| Wizzup | hello powervr | 17:45 |
| uvos | dose this mean it worked? | 17:47 |
| Wizzup | yes | 17:48 |
| Wizzup | touch doens't work | 17:48 |
| Wizzup | but pvr works, display work | 17:48 |
| Wizzup | s | 17:48 |
| uvos | sweet | 17:48 |
| uvos | keyboard also dosent work because your using bionic dts :P | 17:48 |
| Wizzup | yes | 17:48 |
| uvos | i suspect the d3's keyboard matrix is the d4's but with the same mapping for the vol buttons as bionic | 17:49 |
| Wizzup | any clue on touch? | 17:50 |
| uvos | yeah if the touch coordinates are different enough | 17:50 |
| Wizzup | audio works | 17:50 |
| uvos | touchscreen buttons might be freaking out | 17:51 |
| Wizzup | I think there is just no driver (probe fails) | 17:51 |
| uvos | ok | 17:51 |
| uvos | then thats not it | 17:51 |
| uvos | might be a different chip entirely | 17:51 |
| uvos | so do the usual | 17:51 |
| uvos | i2cdetect etc | 17:51 |
| Wizzup | 'usual' :p | 17:51 |
| uvos | the accelerometer should work | 17:52 |
| uvos | its the same one as bionic (as oppsed to d4) | 17:53 |
| Wizzup | can't tell from tklock :p | 17:53 |
| uvos | also we have wl1285c like d4 (as opposed to bionics wl1271) so maserati-callibrate should work | 17:53 |
| uvos | touch is Atmel MXT224E | 17:54 |
| Wizzup | yeah wifi works | 17:54 |
| Wizzup | I need to figure out how to do input/touch | 17:54 |
| Wizzup | :p | 17:54 |
| uvos | d4 has the same touch chip | 17:55 |
| uvos | so thats wierd | 17:55 |
| uvos | regulator might be missconfigured | 17:55 |
| Wizzup | one sec | 17:55 |
| Wizzup | let me log in over usb | 18:00 |
| Wizzup | (easier) | 18:00 |
| Wizzup | Jul 23 17:45:12 localhost kernel: [ 8.709350] atmel_mxt_ts 1-004a: Family: 129 Variant: 1 Firmware V0.4.30 Objects: 18 | 18:01 |
| Wizzup | Jul 23 17:45:12 localhost kernel: [ 8.757965] atmel_mxt_ts 1-004a: Direct firmware load for maxtouch.cfg failed with error -2 | 18:01 |
| Wizzup | Jul 23 17:45:12 localhost kernel: [ 8.822021] atmel_mxt_ts 1-004a: Touchscreen size X1023Y1023 | 18:01 |
| Wizzup | Jul 23 17:45:12 localhost kernel: [ 8.839111] usbcore: registered new interface driver usbfs | 18:01 |
| Wizzup | Jul 23 17:45:12 localhost kernel: [ 8.847015] input: Atmel maXTouch Touchscreen as /devices/platform/44000000.ocp/48000000.interconnect/48000000.interconnect:segment@0/48072000.target-module/48072000.i2c/i2c-1/1-004a/input/input1 | 18:01 |
| Wizzup | I don't see it in xinput though | 18:01 |
| Wizzup | uvos: btw power button works | 18:02 |
| uvos | thats cpcap | 18:02 |
| uvos | yeah | 18:02 |
| uvos | should work | 18:02 |
| uvos | so dose evtest show anything | 18:02 |
| Wizzup | don't have it, just setting up a wifi hotspot, but need to connect to the wifi somehow | 18:02 |
| uvos | because input1 is blacklisted by us via libinput | 18:02 |
| Wizzup | oh, I can do usb for network | 18:03 |
| Wizzup | why do we blacklist it? | 18:03 |
| uvos | or wpa_cli | 18:03 |
| uvos | because of ts-buttons | 18:03 |
| Wizzup | ok | 18:03 |
| uvos | what dose touchscreen-buttons say | 18:03 |
| uvos | dose it bind to the atmel driver? | 18:03 |
| uvos | touchscreen-buttons mapphone_touchscreen: Binding to device: input1 | 18:04 |
| uvos | input: Filtered Touchscreen as /devices/platform/mapphone_touchscreen/input/input4 | 18:04 |
| Wizzup | sec | 18:04 |
| Wizzup | ok so evtest shows ts works | 18:05 |
| Wizzup | uvos: I don't see any touchscreen-buttons in kern.log I think | 18:06 |
| uvos | what kernel are you useing? | 18:06 |
| Wizzup | bionic kernel | 18:07 |
| uvos | hmm ok | 18:07 |
| uvos | so it dosent probe | 18:07 |
| uvos | thats wierd | 18:07 |
| uvos | for now you can rm /lib/udev/rules.d/85-input-devices.rules.leste | 18:07 |
| uvos | to let x use the ts directly | 18:07 |
| Wizzup | and reboot I guess | 18:08 |
| uvos | udevadm trigger might work | 18:08 |
| Wizzup | recall the command? | 18:08 |
| uvos | udevadm trigger | 18:08 |
| uvos | ? | 18:08 |
| Wizzup | it shows in xinput: | 18:09 |
| Wizzup | ⎜ ↳ Atmel maXTouch Touchscreen id=8[slave pointer (2)] | 18:09 |
| Wizzup | (it didn't before) | 18:09 |
| Wizzup | but using it doesn't really seem to work | 18:09 |
| Wizzup | well, I mean, it probably needs calibration | 18:10 |
| uvos | its rotated 90deg now | 18:10 |
| uvos | and uncalibrated | 18:10 |
| uvos | but thats not so bad | 18:10 |
| uvos | (the calibration part) | 18:10 |
| Wizzup | ok, I manually unlocked using dbus | 18:10 |
| Wizzup | and yeah it seems rotated | 18:10 |
| uvos | just rotate the display back an fourth with the acell | 18:11 |
| uvos | (the accel might be in the wrong orientation so rotate the device in varous ways) | 18:11 |
| Wizzup | it's in landscape atm, I don't think it rotates based on accelerometer yet | 18:11 |
| uvos | hildon-desktop-rotate-touchscreen.sh then | 18:12 |
| Wizzup | that did it | 18:12 |
| Wizzup | well... :) | 18:12 |
| uvos | pictures time :P | 18:13 |
| Wizzup | more like video time :p | 18:13 |
| Wizzup | keyboard doesn't work yet, but eh | 18:13 |
| uvos | that should be trival | 18:13 |
| uvos | copy &keypad { from droid4-xt894.dts | 18:14 |
| uvos | and add the vol keys from bionic | 18:14 |
| uvos | but yeah you have some dts cleaning to do | 18:14 |
| uvos | wrt spliting mapphone-common a bit more | 18:14 |
| Wizzup | yeah, and making clownboot work or so | 18:14 |
| uvos | once you have sane dts | 18:15 |
| uvos | that should be easy | 18:15 |
| Wizzup | well the magic trick really was tmlind's info and your modules | 18:15 |
| uvos | was a team effort | 18:16 |
| Wizzup | I'll try to get the keyboard going and make a proper vide | 18:22 |
| Wizzup | o | 18:22 |
| Wizzup | uvos: shall I try to copy the keypad slide from d4 dts? | 18:23 |
| uvos | yeah and add the vol button from bionic | 18:23 |
| uvos | the vol button on d4 and xt910 is on cpcap | 18:24 |
| uvos | on xt875 its on the matrix | 18:24 |
| Wizzup | do you recall (I think you just looked) if the accelerometer is from bionic or d4 | 18:24 |
| uvos | i strongly suspect it is on d3 too | 18:24 |
| uvos | its the bionic one | 18:24 |
| uvos | ktxf9 | 18:24 |
| Wizzup | ok | 18:24 |
| uvos | intterupt pin might be elsewhere | 18:25 |
| uvos | (if it probes but dosent work) | 18:25 |
| Wizzup | so I will take the VOLUMEDOWN from bionic as 3,0 | 18:25 |
| uvos | yeah | 18:25 |
| Wizzup | ok | 18:25 |
| uvos | Wizzup: i fwd you a message about the gpios | 18:27 |
| uvos | in case you need to parse it from dtb | 18:27 |
| Wizzup | regarding key map you mean? | 18:27 |
| Wizzup | ok | 18:27 |
| uvos | no the the accel intterupt (or any other) | 18:27 |
| Wizzup | ok | 18:27 |
| Wizzup | right | 18:27 |
| uvos | if the accel wont work but the driver probes this is the problem | 18:28 |
| Wizzup | ok | 18:30 |
| Wizzup | some of the map is slightly different | 18:31 |
| Wizzup | (keys) | 18:31 |
| uvos | ok | 18:32 |
| Wizzup | it has a mic and search key | 18:32 |
| uvos | should be easy to fix by watchin MS_SCANN | 18:32 |
| Wizzup | where d4 has the SYM | 18:32 |
| Wizzup | volume both work | 18:32 |
| Wizzup | slide not yet I think | 18:32 |
| uvos | the d3 like all the other non cost reduced droids might have 2 slide keys | 18:33 |
| uvos | one for fully closed and one for 3/4 open | 18:33 |
| Wizzup | aha | 18:33 |
| uvos | so that you dont accidentaly wake the device by popping it slightly in you pocket ;) | 18:34 |
| uvos | (somehting i find majorly annoying on d4 btw) | 18:34 |
| Wizzup | well it did freeze up just now, so there might be some things to iron out ;) | 18:39 |
| uvos | you might want to reduce the frequency | 18:39 |
| uvos | the d3 was never clocked at 1.2Ghz by moto | 18:39 |
| uvos | and i has older revision of the omap4 | 18:39 |
| uvos | it might not make it | 18:40 |
| uvos | then again its the same revision as bionic | 18:40 |
| uvos | so idk | 18:40 |
| Wizzup | video incoming | 18:46 |
| Wizzup | https://wizzup.org/droid3-initial-s.mp4 | 18:49 |
| stano_ | elegantly slim | 18:49 |
| stano_ | congrats wizzup ✓ | 18:50 |
| Wizzup | Bus 002 Device 002: ID 22b8:2a70 Motorola PCS modem not visible in ofono yet | 18:51 |
| buZz | nice | 18:52 |
| uvos | Wizzup trys to type uname twice ... gives up :P | 18:53 |
| Wizzup | yeah :-D | 18:54 |
| Wizzup | I forgot I had to press sym + v | 18:54 |
| Wizzup | so I put a sim card in my d3 on android and now it locked me out again | 19:31 |
| Wizzup | lmao what | 19:31 |
| Wizzup | putting it in airplane mode works | 19:32 |
| stano_ | ftl: vncserver -geometry 959x484 on server gives a full window on droid4's vncvlient | 19:33 |
| Wizzup | uvos: ugh this one wants a network unlock code | 19:36 |
| Wizzup | hm: | 20:00 |
| Wizzup | Jul 23 19:57:10 localhost pulseaudio: modules/alsa/alsa-ucm.c:608:pa_alsa_ucm_query_profiles:Failed to get the verb HiFi | 20:00 |
| Wizzup | Jul 23 19:57:10 localhost pulseaudio: modules/alsa/alsa-ucm.c:608:pa_alsa_ucm_query_profiles:Failed to get the verb Voice Call | 20:00 |
| Wizzup | Jul 23 19:57:10 localhost pulseaudio: modules/alsa/alsa-ucm.c:616:pa_alsa_ucm_query_profiles:No UCM verb is valid for Mapphone Audio | 20:00 |
| stano_ | you seem to be the resident pulse/UCM expert :) | 20:12 |
| Wizzup | meh | 20:12 |
| Wizzup | brain is dead today | 20:12 |
| stano_ | brain fog can be a sign of diet in need of correction | 20:13 |
| stano_ | many people are taking far too many complex carbohydrates | 20:13 |
| stano_ | this droid4 keeps losing ability to wlan, scanning stops working, nothing visible anymore | 20:19 |
| stano_ | after installing firmware-ti and maserati-calibrate and reboot even | 20:19 |
| stano_ | and the accesspoing is 90 cm away | 20:19 |
| stano_ | maybe i'll try without calibration | 20:20 |
| uvos | stano_: upgrade | 20:30 |
| uvos | stano_: preferably to devel | 20:30 |
| uvos | stano_: there where issues with wifi in recent packages | 20:31 |
| uvos | stano_: its all fixed tho | 20:31 |
| stano_ | that's great thanks | 20:31 |
| uvos | Wizzup: yeah us d3 is verizon locked afaik | 20:31 |
| uvos | Wizzup: should have bought a milestone 3 instead :P | 20:31 |
| Wizzup | uvos: annoying, that's an added cost then | 20:31 |
| uvos | Wizzup: maybe we can get a milestone 3 and see if we can unlock the d3 by seting the nvmem values like on the m3 | 20:32 |
| uvos | sadly m3s where sold only in south/central america and asia afaik | 20:32 |
| Wizzup | yeah I didn't find any on ebay | 20:33 |
| uvos | a eu version was planned but canceld in favor of a eu m4 that never made it before moto died | 20:33 |
| Wizzup | uvos: either that or unlocking one and comparing nvmem values? | 20:33 |
| uvos | Wizzup: sure if you can | 20:33 |
| Wizzup | there's 10+ websites that will give you a proper unlock code (so they claim) for like 10 bucks | 20:33 |
| uvos | sound shady not gonna lie | 20:34 |
| uvos | maybe if you ask vrz nicely | 20:34 |
| uvos | you could try at least | 20:34 |
| Wizzup | heh | 20:34 |
| Wizzup | I think that's naive, they have a line you can call but you have to be a customer | 20:34 |
| Wizzup | it's not a thing here, but in the US it's common I think | 20:34 |
| uvos | ok | 20:35 |
| Wizzup | I'll probably try it for this one at some point | 20:35 |
| uvos | locked phones? | 20:35 |
| Wizzup | yes | 20:35 |
| uvos | yeah back then in us the cariers dided even allow you to bring your own device | 20:35 |
| uvos | it had to be a vrz device | 20:35 |
| uvos | and they made contracts with device oems to make the deivces | 20:36 |
| uvos | and exclusivity deals | 20:36 |
| uvos | where the picked the soc and sutch even | 20:36 |
| uvos | thats how moto ended up in this terrible situation where they have 100s of variants fo devices with qualcomm msm tegra 2 and omap4 socs | 20:36 |
| uvos | and no resources to support all of them | 20:36 |
| uvos | that basicly sunk them | 20:37 |
| Wizzup | https://www.digitaltrends.com/mobile/how-to-unlock-a-phone-on-every-carrier/ | 20:41 |
| Wizzup | The account holder’s Social Security number or password | 20:41 |
| Wizzup | A completed contract and/or device payment plan | 20:41 |
| Wizzup | yup | 20:41 |
| uvos | nice :P | 20:42 |
| Wizzup | https://sim-unlock.net/simlock/Motorola/Droid_3/ | 20:42 |
| Wizzup | 7 eur | 20:42 |
| uvos | luckly we have our resident guinea pig: Wizzup | 20:43 |
| uvos | dont forget to dump the nvmem first | 20:44 |
| Wizzup | yeah not going to do it yet | 20:44 |
| Wizzup | but when I got it booted I did order a few from ebay so now I'm pissed :D | 20:44 |
| uvos | lol | 20:45 |
| Wizzup | yeah, great stuff :-D | 20:47 |
| uvos | Wizzup: https://forum.xda-developers.com/t/guide-unlock-xt862-for-t-mobile-att.1406812/ | 20:52 |
| uvos | links even still work | 20:52 |
| uvos | looks like thay just flash the m3 raido.img | 20:53 |
| stano_ | after update, ssh to droid4 is still responsive even while playing a movie in vncviewer | 20:55 |
| tmlind | Wizzup: cool you got it configured :) | 21:09 |
| uvos | tmlind: yeah was just the polarty of the data lines | 21:09 |
| uvos | the pannel is the same one | 21:09 |
| uvos | also looks like radiocomm can sim unlock d3 | 21:09 |
| uvos | according to xda | 21:10 |
| uvos | so its in nvmem for sure | 21:10 |
| Wizzup | tmlind: yeah, things to work on, but it's a fun start | 21:10 |
| Wizzup | uvos: got a link? | 21:11 |
| Wizzup | uvos: the the 'a' didn't work on the keyboard | 21:14 |
| Wizzup | that's why I couldn't type uname | 21:14 |
| Wizzup | I need to fix the keymap I think | 21:14 |
| uvos | Wizzup: in the same thread as posted above | 21:15 |
| uvos | Wizzup: thats easy | 21:15 |
| uvos | Wizzup: just check scanncodes with evtest | 21:15 |
| uvos | and ajust acordingly | 21:16 |
| Wizzup | uvos: ah missed it | 21:17 |
| Wizzup | (@ link) | 21:17 |
| Wizzup | uvos: yeah I wil | 21:17 |
| uvos | is parazyd around? | 21:18 |
| uvos | we should probubly rethink how we do the repos and leste-config for mapphones | 21:18 |
| uvos | the current setup dosent scale that well | 21:18 |
| Wizzup | he's more close to me distance wise than usual for sure :p | 21:18 |
| uvos | and now we have 3 mapphones soon to be 4 (mz617) and maybe 6 (mz609, xt91x) | 21:19 |
| uvos | its wierd that audio works for you | 21:20 |
| uvos | but ucm dosent | 21:20 |
| uvos | that seams impossible really | 21:20 |
| Wizzup | pa does not pick it up | 21:21 |
| uvos | wierd | 21:22 |
| Wizzup | (sorry, finger food dinner , hard to type :p) | 21:22 |
| Wizzup | uvos: the card name did match the ucm dir, so I'll debug and figure it out, maybe tomorrow | 21:46 |
| Wizzup | downloaded the unlock.zip (with radio.img), glad the mediafire still exists.. | 21:47 |
| Wizzup | uvos: btw you said the reserved ram isn't necessary right? | 21:51 |
| uvos | yeah | 21:51 |
| uvos | the stock kernel dosent do it | 21:51 |
| uvos | (saw in your dmesg) | 21:51 |
| Wizzup | ok | 21:51 |
| Wizzup | check | 21:51 |
| uvos | we should maybe try and reclaim it on d4 too | 21:52 |
| uvos | i dont see a reason for mbm to be mapped to ram all the time | 21:52 |
| Wizzup | not first thing on my list but yeah :p | 21:53 |
| uvos | and no idea what mb 1023 eve is | 21:53 |
| uvos | *even | 21:53 |
| uvos | yeah 2mb isent a huge deal on d4 | 21:53 |
| Wizzup | I am hoping that for everything but browsing ~250MB will be enough for leste | 21:54 |
| Wizzup | we'll see how that pans out | 21:54 |
| uvos | gona be tight when you start to update toolkits | 21:54 |
| Wizzup | gtk3 much worse? | 21:54 |
| uvos | yeah the theaming engine | 21:55 |
| uvos | same with qt5,6 | 21:55 |
| uvos | freemantle hovers at 200mb after boot allready | 21:55 |
| Wizzup | mhm, we have thumb though, but we'll see | 21:56 |
| uvos | i honestly dont see how we can keep the n900 going mutch longer (other than just not updateing leste to new tech) | 21:56 |
| Wizzup | just for the record it is 'fremantle' not 'freemantle' | 21:56 |
| Wizzup | uvos: yeah this is not about the n900 per se really | 21:56 |
| uvos | ~250MB will be enough for leste sounds pretty n900ish to me :P | 21:56 |
| Wizzup | it does but I didn't mean it | 21:56 |
| uvos | ok | 21:57 |
| Wizzup | as in, the d3 is pretty neat too imho | 21:57 |
| uvos | well it has 512, i think thats more realistic | 21:57 |
| Wizzup | mhm | 21:58 |
| Wizzup | I mean, zram on n900 almost gets you there too :P | 21:58 |
| sixwheeledbeast | https://en.wikipedia.org/wiki/Fremantle_Doctor Nokia named versions after winds hence choice of https://en.wikipedia.org/wiki/Leste | 22:00 |
| Wizzup | yeah | 22:00 |
| uvos | yeah its neat | 22:00 |
| Wizzup | also I think if the sim unlock works, that means the d3 will work in the us | 22:01 |
| uvos | yes | 22:01 |
| Wizzup | whereas the d4 does not | 22:01 |
| uvos | thats an advatage | 22:01 |
| uvos | same as bionic | 22:01 |
| Wizzup | +keyboard,-ram | 22:02 |
| uvos | yeah | 22:02 |
| Wizzup | I'll take it | 22:02 |
| uvos | btw with d4 2 tabs open in ff, mpd running and asileriot open i am at 378mb useage (this is just what i had open at the moment) | 22:03 |
| uvos | so even browsing should be fine on d3 | 22:03 |
| Wizzup | mhm, we also have zram there | 22:04 |
| stano_ | is there a way to see why ssh sessions and pings suddenly go to really slow (20sec - 1 minute) response times? | 22:05 |
| uvos | wifi chip is asleap | 22:05 |
| Wizzup | stano_: ping from or to device> | 22:07 |
| stano_ | ping to device. i see pinging using the d4 works just fine | 22:08 |
| stano_ | so ping -i 5 <ap addr> seems to keep things awake often enough | 22:08 |
| Wizzup | try iw dev wlan0 set power_save off | 22:08 |
| Wizzup | (iirc that is the syntax) | 22:08 |
| stano_ | oh ty | 22:08 |
| Wizzup | it will increase power usage, but you will not see the slowdowns anymore | 22:08 |
| Wizzup | wifi does deep sleeps unless the device transmits, it doens't care much for outside comms (but with enough pings, you can wake it up) | 22:09 |
| Wizzup | there is a checkbox for this in the UI, but it is not yet implemented | 22:09 |
| Wizzup | see https://github.com/maemo-leste/bugtracker/issues/172 | 22:09 |
| stano_ | that archos 80 with omap3 could run leste too | 22:18 |
| stano_ | but it'd just be one to add another device to the list. few people have it. | 22:19 |
| uvos | stano_: sure anything can run leste, if you put the work into it | 22:20 |
| stano_ | and the kernel i have is superold | 22:20 |
| stano_ | yea | 22:20 |
| uvos | stano_: with other mapphones its easy since they are all the same | 22:20 |
| uvos | stano_: so geting up to date kernel going is pretty trivial | 22:20 |
| stano_ | not all kinds of weird peripherals? | 22:21 |
| stano_ | those probably are good targets then | 22:21 |
| uvos | not mutch the peripherals and cpcap setup varies only tiny bit | 22:23 |
| uvos | ofc we dont really know, some other random mapphone like atrix 2 might have totaly different sensors or something, but its unlikely | 22:24 |
| stano_ | seeing 2-3.2ms pings arm :) it's so nice | 22:25 |
| stano_ | *atm | 22:25 |
| Wizzup | uvos: I don't have/drive a car, but if I had I'm definitely try to make it work on some in-car thing | 22:44 |
| Wizzup | seems like a decent fit imho | 22:45 |
| uvos | Wizzup: the d3? | 22:45 |
| Wizzup | nah, leste | 22:45 |
| uvos | oh | 22:46 |
| Wizzup | I'm not _that_ _delusional_ / hyped :p | 22:46 |
| Wizzup | hm only meant that for the second word | 22:46 |
| uvos | im confused | 22:46 |
| uvos | do you want to run leste on some infotainment system? :P | 22:46 |
| uvos | or a car mode app for leste? | 22:47 |
| uvos | like android has | 22:47 |
| stano_ | i think TI got a lot of omaps into car systems | 22:47 |
| Wizzup | infotainment yeah, or for directions | 22:47 |
| Wizzup | uvos: I mean infotainment but useful yeah | 22:47 |
| uvos | Wizzup: ok to be clear you want to run leste on a car build in infotaiment system hardware or write a infotainment application for leste phones/tablets | 22:48 |
| Wizzup | uvos: former | 22:49 |
| Wizzup | ok, apparently the 'a' key is type 4 (EV_MSC), code 4 (MSC_SCAN), value 3d | 22:50 |
| uvos | do you have a particular model in mind? | 22:50 |
| Wizzup | car? | 22:50 |
| Wizzup | my knowledge of cars is really close to nothing, so no :) | 22:50 |
| uvos | well infotainment system | 22:50 |
| Wizzup | I also don't drive one | 22:50 |
| uvos | the car its install in is secondary | 22:50 |
| Wizzup | I don't know, I just know that some cars have like android built in :) | 22:51 |
| uvos | this seams a bit random | 22:51 |
| uvos | :P | 22:51 |
| uvos | but would be cool no doubt | 22:51 |
| uvos | i also dont drive for the record | 22:51 |
| Wizzup | uvos: so I have the key codes, how do I actually get it to pass the 'a' key properly | 22:51 |
| Wizzup | I just see MATRIX_KEY macros (presumably) | 22:51 |
| uvos | 1sec | 22:52 |
| uvos | you should get something like: type 4 (EV_MSC), code 4 (MSC_SCAN), value 2f | 22:52 |
| uvos | do you not get a value? | 22:52 |
| Wizzup | yes, see above | 22:52 |
| Wizzup | 22:50 < Wizzup> ok, apparently the 'a' key is type 4 (EV_MSC), code 4 (MSC_SCAN), value 3d | 22:53 |
| uvos | oh i missed it somehow | 22:53 |
| uvos | ok so its 3, d> in the macro or maybe d, 3> i dont quite remember but the corrispondance was obvious when i was doing this for bionic | 22:54 |
| Wizzup | oh, so MATRIX_KEY does not correspond to the matrix on the keyboard or something | 22:54 |
| Wizzup | oh, wait, I see | 22:54 |
| Wizzup | maybe it's 0x3 and 0xd ? | 22:56 |
| uvos | yeah | 22:58 |
| uvos | its really obvious | 22:58 |
| uvos | just type a key that works | 22:58 |
| uvos | and see | 22:58 |
| Wizzup | I mean there is no MATRIX_KEY in arch/arm/boot/dts that uses a value above 0x7 i seems | 22:58 |
| Wizzup | hm, if I type a key in that works, I won't see the value | 22:58 |
| Wizzup | unless I comment it | 22:58 |
| uvos | ? | 22:58 |
| uvos | you should see all values | 22:58 |
| uvos | i can see all of them on d4 | 22:58 |
| Wizzup | the value will be 0 or 1, depending on if it is pressed | 22:58 |
| Wizzup | no? | 22:58 |
| uvos | no | 22:58 |
| Wizzup | maybe you're using a program other than evtest | 22:59 |
| uvos | you get a msc_scann event too | 22:59 |
| uvos | no | 22:59 |
| Wizzup | hm | 22:59 |
| uvos | you get a key event | 22:59 |
| uvos | and a scann event | 22:59 |
| Wizzup | check | 22:59 |
| Wizzup | Event: time 1627073983.311370, type 4 (EV_MSC), code 4 (MSC_SCAN), value 17 | 22:59 |
| Wizzup | Event: time 1627073983.311370, type 1 (EV_KEY), code 31 (KEY_S), value 1 | 22:59 |
| uvos | right | 23:00 |
| uvos | so now you can reverse engeneer the macro | 23:00 |
| uvos | thats how i did it | 23:00 |
| Wizzup | MATRIX_KEY(2, 7, KEY_S) | 23:00 |
| uvos | ofc you could also read the documentation | 23:00 |
| uvos | but thats boring | 23:00 |
| Wizzup | :p | 23:00 |
| Wizzup | #define MATRIX_KEY(row, col, code) \ ((((row) & 0xFF) << 24) | (((col) & 0xFF) << 16) | ((code) & 0xFFFF)) | 23:02 |
| inky | did anyone try pinephone or droid4 with some debian camera program? | 23:02 |
| stano_ | usb camera? | 23:03 |
| inky | is it a name of the program? | 23:06 |
| Wizzup | inky: does the droid4 camera work then? | 23:06 |
| inky | or you mean if i connected usb camera? | 23:06 |
| uvos | inky cameras cant work on d4 | 23:07 |
| uvos | on pp they might, not sure if we have the relevant patches | 23:07 |
| uvos | but its possible at least | 23:07 |
| uvos | usb cameras over otg should work ofc | 23:07 |
| inky | a right, it's not working. but on pp? | 23:07 |
| Wizzup | uvos: funny how it's obvious to you and not at all to me :-D | 23:08 |
| inky | camera support is not on wiki for pinephone. (: | 23:08 |
| uvos | ^^^ thats bait | 23:08 |
| Wizzup | more specifically it's not clear to me how the msc_scan value in any way relates to the row/column that one can pick, which are determined from the row/column gpios | 23:09 |
| Wizzup | per https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt | 23:09 |
| Wizzup | ah I guess it is https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-keys.txt | 23:10 |
| Wizzup | nope | 23:10 |
| uvos | Wizzup: fine ill take a look :P | 23:10 |
| uvos | no | 23:10 |
| Wizzup | nah, I can look tomorrow as well, I'm just tired now I guess | 23:10 |
| Wizzup | https://www.kernel.org/doc/Documentation/devicetree/bindings/input/omap-keypad.txt | 23:11 |
| Wizzup | defined in omap4-l4.dtsi it looks like | 23:12 |
| Wizzup | meanwhile gpio122 is indeed changed by the slider | 23:14 |
| Wizzup | (I exported it in /sys/class/gpio and the value changes with the slider) | 23:14 |
| Wizzup | yeah I misdefined it in the dts :) | 23:17 |
| Wizzup | (the slider) | 23:17 |
| uvos__ | [23:13] <uvos> ok so on d4 | 23:17 |
| uvos__ | [23:13] <uvos> key 7 | 23:17 |
| uvos__ | [23:13] <uvos> is 0 1 | 23:17 |
| uvos__ | [23:14] <uvos> and key 2 is 0 6 | 23:17 |
| uvos__ | [23:14] <uvos> scann of 7 is 6 | 23:17 |
| uvos__ | [23:14] <uvos> scann of 7 is 1 | 23:17 |
| uvos__ | [23:14] <uvos> and scann of 2 is 6 | 23:17 |
| uvos__ | [23:14] <uvos> then r is 1 0 | 23:17 |
| uvos__ | [23:14] <uvos> and r is scan 8 | 23:17 |
| uvos__ | [23:15] <uvos> see a pattern? | 23:17 |
| uvos__ | [23:15] <uvos> its | 23:17 |
| uvos__ | [23:15] <uvos> keypad,num-rows = <8>; | 23:17 |
| uvos__ | [23:15] <uvos> keypad,num-columns = <8>; | 23:17 |
| uvos__ | [23:16] <uvos> so a is 7, 5> on d3 | 23:17 |
| uvos__ | [23:16] <uvos> Wizzup: ^^^ | 23:17 |
| uvos | in c pseduo code its MATRIX_KEY(MSC_SCAN >> 1, MSC_SCAN%8, KEY_0) | 23:19 |
| Wizzup | one second | 23:19 |
| Wizzup | wen you write MSC_SCAN, do you mean the value of MSC_SCAN? | 23:23 |
| uvos | yes | 23:24 |
| uvos | so a is MATRIX_KEY(0x3d >> 1, 0x3d % 8, KEY_A) | 23:24 |
| Wizzup | per your formula I don't see how that gets to 7,5 | 23:24 |
| Wizzup | 0x3d>>1 = 30 | 23:25 |
| uvos | no 0x3d = 61 | 23:25 |
| uvos | mod(61, 8) = 7 | 23:25 |
| uvos | according to my calcualtor | 23:25 |
| uvos | rm = 5 | 23:25 |
| uvos | and 61 / 8 = 7.soemthing | 23:26 |
| uvos | so 7 | 23:26 |
| uvos | * mod(61, 8) = 5 ofc | 23:26 |
| Wizzup | maybe you don't mean >> 1 then? | 23:26 |
| uvos | yes | 23:26 |
| uvos | i ment /8 | 23:26 |
| uvos | not /2 | 23:26 |
| uvos | its /keypad,num-rows | 23:26 |
| uvos | and then the floor of that | 23:26 |
| uvos | sry | 23:26 |
| uvos | MATRIX_KEY((int)(0x3d/8), 0x3d % 8, KEY_A) | 23:27 |
| uvos | that should do it | 23:27 |
| Wizzup | ok, yeah, so just mod and div then | 23:27 |
| Wizzup | slider works now, btw :) | 23:27 |
| uvos | great | 23:27 |
| uvos | was it a gpio key? | 23:28 |
| Wizzup | no, it was my not defining the gpio-keys compatible | 23:28 |
| uvos | how many slider keys do we have on d3? | 23:28 |
| uvos | ok | 23:28 |
| Wizzup | the gpio is the same as the d4 | 23:28 |
| uvos | ok | 23:28 |
| Wizzup | I don't know if there are more | 23:28 |
| uvos | ok | 23:28 |
| uvos | check with androids version of evtest i gues (on android) | 23:28 |
| Wizzup | for msc_scan ? | 23:28 |
| uvos | "getevent" | 23:29 |
| Wizzup | not sure what you mean | 23:29 |
| uvos | no if another slider switch exitsts | 23:29 |
| uvos | getevent == evtest (but on android) | 23:29 |
| Wizzup | btw, the microphone key currently is leftalt (which makes sense I guess) | 23:29 |
| Wizzup | and then the search key is KEY_MINUS (less ok) | 23:29 |
| Wizzup | and the @ key next to it is KEY_EQUAL | 23:29 |
| uvos | but d3 has a alt already no? | 23:30 |
| Wizzup | alt is ctrl | 23:30 |
| uvos | where shift is on d4 | 23:30 |
| uvos | ok | 23:30 |
| Wizzup | no :d | 23:30 |
| uvos | uh | 23:30 |
| Wizzup | shift is shift | 23:30 |
| Wizzup | alt=control | 23:30 |
| Wizzup | mic=alt | 23:30 |
| uvos | hmm sounds confusing | 23:30 |
| uvos | maby have alt=alt and mic=ctrl | 23:30 |
| Wizzup | https://upload.wikimedia.org/wikipedia/commons/a/a6/DROID_3.jpg | 23:31 |
| uvos | wierd that they have shift where capslock is on d4 | 23:31 |
| uvos | and we switched it back :P | 23:31 |
| Wizzup | yeah | 23:31 |
| Wizzup | yup | 23:31 |
| uvos | at least you muscel memory will be all right :P | 23:31 |
| Wizzup | not looking forward to doing the xkb-data | 23:32 |
| uvos | the keyboard looks way nicer | 23:33 |
| uvos | all those special keys have labels | 23:33 |
| Wizzup | yeah, the led is also in a nicer place imho | 23:33 |
| Wizzup | and it doesn't auto turn on when the usb is connected :p | 23:33 |
| Wizzup | so now I can actually have mce do a proper pattern | 23:33 |
| Wizzup | ;) | 23:34 |
| uvos | it has another white charge led by the usb input like d1 or? | 23:34 |
| Wizzup | yeah | 23:34 |
| Wizzup | uvos: do you recall what should be done to enable the charging pattern in led-sw (to have it be anything) | 23:38 |
| Wizzup | mce.ini says # Charging = orange tinted, should be pulsating, but we don't do that atm in led-sw | 23:38 |
| uvos | 70-bionic.ini disabels it | 23:39 |
| Wizzup | oh, nvm | 23:39 |
| Wizzup | yeah | 23:39 |
| Wizzup | just realised | 23:39 |
| uvos | but if the white usb led works | 23:40 |
| uvos | i would keep it disabled | 23:40 |
| Wizzup | I want to see blink blink :-) | 23:40 |
| uvos | but a dedicated light is better :P | 23:41 |
| Wizzup | not really, it's on the side and not visible | 23:41 |
| uvos | i dissagree | 23:41 |
| uvos | but ok | 23:41 |
| Wizzup | :D | 23:41 |
| Wizzup | it's kind of on the bottom/side and not visible (the white one) | 23:42 |
| Wizzup | and it would not be visible at all if hdmi was also plugged in | 23:42 |
| Wizzup | oh, it would be | 23:42 |
| Wizzup | still | 23:42 |
| uvos | pff you can barstardize that unit as mutch as you want :D | 23:43 |
| uvos | anyhow ttyl | 23:43 |
| Wizzup | hehe | 23:43 |
| Wizzup | ttyl | 23:43 |
| Wizzup | that's part of the fun, no | 23:43 |
| inky | today i connected the jack to droid4, my friend helped me to have the jack (aux?) input in the car radio, so i use phone via jack usually to play something, and it seems that droid didn't understand something is connected to the jack. is it right? | 23:45 |
| Wizzup | inky: yes, you need to select that specifically | 23:45 |
| Wizzup | (currently) | 23:45 |
| Wizzup | install pavucontrol-qt and set it in the output devices tab | 23:45 |
| inky | yay. | 23:45 |
| Wizzup | we're working on fixing that (uvos on the kernel side, me on userspace) | 23:45 |
| inky | i had pulseaudio scripts on sailfish to do that when sailfish was not able to do that on xperia. | 23:45 |
| Wizzup | nice, there's also a shift key led | 23:52 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
