<Wizzup>
Jul 23 09:28:49 localhost kernel: [ 7.827301] lm75: probe of 0-0048 failed with error -121
rafael2k has joined #maemo-leste
Pali has joined #maemo-leste
rafael2k has quit [Ping timeout: 256 seconds]
uvos has joined #maemo-leste
<uvos>
Wizzup: sweet looks like mosty everything works :)
<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
<uvos>
i have no idea on the dsi, really
<uvos>
other than to, again, compear the stock kernel between d3 and bionic
<Wizzup>
ok
<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
<tmlind>
the motorola dtb is non-standard endian, just look at it with a hex editor and compare to droid4 and bionic
<tmlind>
the property to look at is probably named Display@0
stano_ has quit [Ping timeout: 265 seconds]
<tmlind>
hmm actually it's easier to get the info from the stock kernel dmesg
<tmlind>
and then you need to configure the backlight controller
stano_ has joined #maemo-leste
stano__ has joined #maemo-leste
<tmlind>
maybe post the stock kernel dmesg output somewhere to look at?
<uvos>
wich i assume tells us if the fw of the lcd is configured for video mode or not
<Wizzup>
ok, yeah, I can install safestrap 3.x in a bit
<Wizzup>
xxd doesn't make much sense of that device tree as is
<uvos>
the data for the display is at 0x250
<uvos>
but dont ask me how to interpret it
<Wizzup>
Let me see if I can pull in okteta without the entirety of kde
alex1216 has joined #maemo-leste
<Wizzup>
(nope)
<uvos>
bless then?
<Wizzup>
trying wxhexeditor atm
<Wizzup>
lol it writes "Rahman ve Rahim olan Allah'ın adıyla." on exit
<Wizzup>
ok
alex1216 has quit [Ping timeout: 272 seconds]
Kabouik_ is now known as Kabouik
uvos has quit [Read error: Connection reset by peer]
elastic_dog has quit [Ping timeout: 255 seconds]
inky_ has quit [Ping timeout: 258 seconds]
diejuse has quit [Quit: Leaving.]
<Wizzup>
yeah so it looks like the dtc opcodes are the opposite endianness, but the strings are not, obviously
elastic_dog has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
hi
<uvos>
Wizzup: did you get anywhere in my absense
<uvos>
i dont think you accutally need to decompile the dtb
<uvos>
you just have to figure out how d1_pos .. dn_pos mapps to mainline dts
<Wizzup>
uvos: I'm having trouble reading the dtb properly, did you see the one I uplodaed?
<uvos>
sure but that would not help us that much anyhow
<uvos>
it contains the same info
<uvos>
and then we still dont know how the bindings work for mainline
<Wizzup>
ok
<uvos>
just look at the mainline dts binding doucmentation
<Wizzup>
let me make a coffee first
<Wizzup>
btw, it would still be good see if we can find the dts patch somewhere
<uvos>
i suspect d1...d5 that is the only difference between d4 and d3 corrisponds to lanes = <0 1 2 3 4 5>;
<uvos>
somehow
<Wizzup>
there might be more devices where we want this
<uvos>
but thats just my guess
<Wizzup>
uvos: yeah I also saw the lanes in dmesg
inky_ has joined #maemo-leste
<uvos>
Wizzup: sure @patch
<uvos>
i want to do xt910 at some point
<uvos>
so yeah
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
<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
<uvos>
thats also why the d4 is so mutch thicker than d1-3
<Wizzup>
mhm
<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 ?
<uvos>
yeah
<Wizzup>
grepping for lanes should indeed different orders (say in 950 dts)
<Wizzup>
not quite sure where I can find the dsi port/lanes info yet (grepping my way around Documentation/device-tree)
<Wizzup>
it looks like the panel doc is display/panel/panel-dsi-cm.yaml - but it doesn't mention the port
<Wizzup>
maybe ./display/ti/ti,omap4-dss.txt ?
<Wizzup>
DSI Endpoint required properties:
<Wizzup>
- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, DATA1+, DATA1-, ...
<Wizzup>
uvos: ^^ ?
<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?
<Wizzup>
not sure what the '*_pos=1' means
<uvos>
Wizzup: clk_lane on d4 i s0
<uvos>
*Wizzup: clk_lane on d4 is 0
<Wizzup>
as opposed to 1, you mean?
<uvos>
yeah
<uvos>
sec
<Wizzup>
the thing is that the <lanes> mentions pos and neg
<Wizzup>
but the dmesg talks about 3 lanes only
<uvos>
so dose dmseg
<uvos>
clk_pos is clk+
<Wizzup>
so I figured the _pos=1 means os comes first or something
<stano_>
that archos 80 with omap3 could run leste too
<stano_>
but it'd just be one to add another device to the list. few people have it.
<uvos>
stano_: sure anything can run leste, if you put the work into it
<stano_>
and the kernel i have is superold
<stano_>
yea
<uvos>
stano_: with other mapphones its easy since they are all the same
<uvos>
stano_: so geting up to date kernel going is pretty trivial
<stano_>
not all kinds of weird peripherals?
<stano_>
those probably are good targets then
<uvos>
not mutch the peripherals and cpcap setup varies only tiny bit
<uvos>
ofc we dont really know, some other random mapphone like atrix 2 might have totaly different sensors or something, but its unlikely
<stano_>
seeing 2-3.2ms pings arm :) it's so nice
<stano_>
*atm
rafael2k has quit [Ping timeout: 252 seconds]
rafael2k has joined #maemo-leste
<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
<Wizzup>
seems like a decent fit imho
<uvos>
Wizzup: the d3?
<Wizzup>
nah, leste
<uvos>
oh
<Wizzup>
I'm not _that_ _delusional_ / hyped :p
<Wizzup>
hm only meant that for the second word
<uvos>
im confused
<uvos>
do you want to run leste on some infotainment system? :P
<uvos>
or a car mode app for leste?
<uvos>
like android has
<stano_>
i think TI got a lot of omaps into car systems
<Wizzup>
infotainment yeah, or for directions
<Wizzup>
uvos: I mean infotainment but useful yeah
<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
<Wizzup>
uvos: former
<Wizzup>
ok, apparently the 'a' key is type 4 (EV_MSC), code 4 (MSC_SCAN), value 3d
<uvos>
do you have a particular model in mind?
<Wizzup>
car?
<Wizzup>
my knowledge of cars is really close to nothing, so no :)
<uvos>
well infotainment system
<Wizzup>
I also don't drive one
<uvos>
the car its install in is secondary
<Wizzup>
I don't know, I just know that some cars have like android built in :)
<uvos>
this seams a bit random
<uvos>
:P
<uvos>
but would be cool no doubt
inky has joined #maemo-leste
<uvos>
i also dont drive for the record
<Wizzup>
uvos: so I have the key codes, how do I actually get it to pass the 'a' key properly
<Wizzup>
I just see MATRIX_KEY macros (presumably)
<uvos>
1sec
<uvos>
you should get something like: type 4 (EV_MSC), code 4 (MSC_SCAN), value 2f
<uvos>
do you not get a value?
<Wizzup>
yes, see above
<Wizzup>
22:50 < Wizzup> ok, apparently the 'a' key is type 4 (EV_MSC), code 4 (MSC_SCAN), value 3d
<uvos>
oh i missed it somehow
<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
<Wizzup>
oh, so MATRIX_KEY does not correspond to the matrix on the keyboard or something
<Wizzup>
oh, wait, I see
<Wizzup>
maybe it's 0x3 and 0xd ?
<uvos>
yeah
<uvos>
its really obvious
<uvos>
just type a key that works
<uvos>
and see
<Wizzup>
I mean there is no MATRIX_KEY in arch/arm/boot/dts that uses a value above 0x7 i seems
<Wizzup>
hm, if I type a key in that works, I won't see the value
<Wizzup>
unless I comment it
<uvos>
?
<uvos>
you should see all values
<uvos>
i can see all of them on d4
<Wizzup>
the value will be 0 or 1, depending on if it is pressed
<Wizzup>
no?
<uvos>
no
<Wizzup>
maybe you're using a program other than evtest
<uvos>
you get a msc_scann event too
<uvos>
no
<Wizzup>
hm
<uvos>
you get a key event
<uvos>
and a scann event
<Wizzup>
check
<Wizzup>
Event: time 1627073983.311370, type 4 (EV_MSC), code 4 (MSC_SCAN), value 17
<Wizzup>
Event: time 1627073983.311370, type 1 (EV_KEY), code 31 (KEY_S), value 1
<inky>
did anyone try pinephone or droid4 with some debian camera program?
<stano_>
usb camera?
<inky>
is it a name of the program?
<Wizzup>
inky: does the droid4 camera work then?
<inky>
or you mean if i connected usb camera?
<uvos>
inky cameras cant work on d4
<uvos>
on pp they might, not sure if we have the relevant patches
<uvos>
but its possible at least
<uvos>
usb cameras over otg should work ofc
<inky>
a right, it's not working. but on pp?
<Wizzup>
uvos: funny how it's obvious to you and not at all to me :-D
<inky>
camera support is not on wiki for pinephone. (:
<uvos>
^^^ thats bait
<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
<uvos>
wierd that they have shift where capslock is on d4
<uvos>
and we switched it back :P
<Wizzup>
yeah
<Wizzup>
yup
<uvos>
at least you muscel memory will be all right :P
<Wizzup>
not looking forward to doing the xkb-data
<uvos>
the keyboard looks way nicer
<uvos>
all those special keys have labels
<Wizzup>
yeah, the led is also in a nicer place imho
<Wizzup>
and it doesn't auto turn on when the usb is connected :p
<Wizzup>
so now I can actually have mce do a proper pattern
<Wizzup>
;)
<uvos>
it has another white charge led by the usb input like d1 or?
<Wizzup>
yeah
<Wizzup>
uvos: do you recall what should be done to enable the charging pattern in led-sw (to have it be anything)
<Wizzup>
mce.ini says # Charging = orange tinted, should be pulsating, but we don't do that atm in led-sw
<uvos>
70-bionic.ini disabels it
<Wizzup>
oh, nvm
<Wizzup>
yeah
<Wizzup>
just realised
<uvos>
but if the white usb led works
<uvos>
i would keep it disabled
<Wizzup>
I want to see blink blink :-)
<uvos>
but a dedicated light is better :P
Pali has quit [Ping timeout: 265 seconds]
Pali_ has joined #maemo-leste
Pali_ is now known as Pali
<Wizzup>
not really, it's on the side and not visible
<uvos>
i dissagree
<uvos>
but ok
<Wizzup>
:D
<Wizzup>
it's kind of on the bottom/side and not visible (the white one)
<Wizzup>
and it would not be visible at all if hdmi was also plugged in
<Wizzup>
oh, it would be
<Wizzup>
still
<uvos>
pff you can barstardize that unit as mutch as you want :D
<uvos>
anyhow ttyl
<Wizzup>
hehe
<Wizzup>
ttyl
<Wizzup>
that's part of the fun, no
<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?
<Wizzup>
inky: yes, you need to select that specifically
<Wizzup>
(currently)
<Wizzup>
install pavucontrol-qt and set it in the output devices tab
<inky>
yay.
<Wizzup>
we're working on fixing that (uvos on the kernel side, me on userspace)
<inky>
i had pulseaudio scripts on sailfish to do that when sailfish was not able to do that on xperia.
<Wizzup>
nice, there's also a shift key led
<Wizzup>
uvos: I think the ucm stuff fails because the call volume is not avail
<Wizzup>
Jul 24 00:11:56 localhost kernel: [ 17.686828] phy-mapphone-mdm6600 usb-phy@1: Powered up OK
* Wizzup
zzz
<inky>
uvos, is it possible to accept characters from 'some language' and english always? if that is the case then english + other language will always work in x11 programs.
<inky>
i won't type setxkb each time in maemo terminal.
<inky>
though maemo terminal helps a lot, because it always accepts both layouts.