<bencoh>
sounds like something we could do as well I guess
<uvos>
it just communicates with the propriatary fw
<Wizzup>
btw, looks like kernel makes input devices on my laptop too
<Wizzup>
*through* alsa
<Wizzup>
(probably using the phantom_jack=true)
<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
<bencoh>
yeah, alsa uses evdev to report jack events
<bencoh>
at least that's how many devices do it
<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/)
<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
<bencoh>
indeed
<bencoh>
well, iiuc as well
<bencoh>
(alsa isn't exactly the simplest linux API ...)
<uvos>
asoc drivers dont use snd_jack_report
<Wizzup>
huh?
<Wizzup>
they use snd_soc_jack_report
<uvos>
no existing driver uses that fn
<Wizzup>
which is provided by sound/soc/soc-jack.c
<uvos>
asoc drivers a genererally are really ideosnycranous
<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?
<uvos>
well hopefully not since that would not be sufficant to remove the simlock
<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
<Wizzup>
I have 7 more here, so if that works we can try to do those dumps
<tmlind>
ok, interesting
<Wizzup>
looking forward to that beer if it works :P
* dreamer
puts stack of droid4s on buZz desk
<tmlind>
yeh me too :)
<uvos>
but d3 look mutch fancier on a desk
<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
<tmlind>
uvos: are you able to use your bionic with 3g?
<uvos>
yes
<tmlind>
ok
<uvos>
it worked once on o2
<uvos>
but i cant retest now
<uvos>
since umts network is gohne in germany
<tmlind>
ok well i can't see any networks with my sim on bionic for some reason
<uvos>
also not gsm?
<tmlind>
not sure if i tried that, my us sim shows another operators network on 3g
<Wizzup>
well it's definitely reading the 128Mb flash
<uvos>
what 128mb flash?
<Wizzup>
don't know :)
<Wizzup>
I'll share the log in a sec
<uvos>
the lte modem on d4 has 128mb flash
<uvos>
but...
<uvos>
i gues the qcom modem might too
<mighty17[m]>
<tmlind> "mighty17: sorry i have really no..." <- oh ok, i'll ask xc racer
<Wizzup>
yes, it connected to my XS4ALL network :)
<Wizzup>
uvos: yes, would be nice to do one day, but not this day :)
<Wizzup>
maybe when leste is my daily driver
<buZz>
4droid4s even :P niiiice
<uvos>
looks like the qcom modem has a H8BCS0QG0MMR
<buZz>
8 core mobile!
<buZz>
:D
<The_Niz>
:)
<uvos>
and android can clearly read it
<uvos>
sooo
<uvos>
hmm
<Wizzup>
uvos: yeah it requires a rooted device
<uvos>
the shit they hide in these things
<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
<uvos>
(the phones)
<Wizzup>
and then they have a way to send that key, perhaps to the modem
<Wizzup>
there is an android gui to enter an unlock key
<Wizzup>
it did also write to the 'security area' so idk what it does exactly
<Wizzup>
but we can figure it out in the future since I have (counts...) 7 more
* tmlind
probably owes another pint of beer
<tmlind>
Wizzup: maybe also give it a try on your droid4 to see if it can dump out some info
<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)
<Wizzup>
(for the d4 specifically, wrt frequencies I mean)
<tmlind>
Wizzup: also, i posted a patch to add module options to phy-cpcap-mapphone to expose the mdm6600 to the pc usb port
<uvos>
neat
<Wizzup>
ah, cool, so one can run ofono on their pc
<uvos>
well the gpios wont work
<uvos>
but sure qmi only
<Wizzup>
right
<tmlind>
that's for reflashing the modem so two usb uart modes, that's probably what the sigmakey also needs
<tmlind>
then there's another mode not yet implemented that just puts the booted modem to the usb port for pc for qmi
<tmlind>
i think it's just another variation of the mode gpios or something trivial like that
<Wizzup>
sigmakey did everything from adb as far as I can tell
<tmlind>
oh interesting
<Wizzup>
and it requires a rooted android, so it probably uploads software to it to read stuff
<tmlind>
maybe it did adb reboot bootloader to some modem service mode
<Wizzup>
no, the device was unlocked and then restarted
<tmlind>
hmm
<Wizzup>
once it did that it also lost the qemu usb, so there's no way it could do more
<tmlind>
from android the modem can be put into flash mode yeah
<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
<Wizzup>
s/stuff/sniff/
<Wizzup>
but it also performs some calc on the pc itself afaik
<Wizzup>
in any case we can do this as often as we want for free now
dgamer69 has joined #maemo-leste
<uvos>
at Wizzups house anyways
<uvos>
doing it remotely will also be involved
<uvos>
btw adb works over the network too
<uvos>
so if it really only uses adb
<uvos>
...
<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
<tmlind>
the update-binary is there in the modem firmware blob
<Wizzup>
uvos: I think usbip should work, I will try that next
<Wizzup>
it was already confirmed to work on the android forums
<Wizzup>
tmlind: ah
<Wizzup>
uvos: actually qemu has usbredir so that's easier
_inky has quit [Ping timeout: 252 seconds]
<Wizzup>
can work with*
<Wizzup>
I remember doing that many years ago to forward a usb cd drive to my home from sofia
<Wizzup>
in any case the point was that this can be done networked
<Wizzup>
otherwise I wouldn't have gotten the damn dongle :p
<uvos>
"forward a usb cd drive to my home from sofia" lol
<Wizzup>
it was slow to rip but it worked :)
<dgamer69>
I'm trying to get decent perfomance on my maemo leste qemu instance
<dgamer69>
and I got reccomended accelerated grphics
<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
<uvos>
that sounds like the least sane way to rip a cd to some place over the network
<uvos>
but ok :P
<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
<Wizzup>
and I had to test ripping
<Wizzup>
only later I found cdemu which was slightly easier ;)
<Wizzup>
the native orientation is landscape I think of this screen
<uvos>
yeah mulitplying everything with 0 will make the event allways be at 0 0
<uvos>
what dose xinput map-to-output do?
<uvos>
set the Coordinate Transformation Matrix to the identiy matrix first
<Wizzup>
1,0,0 0,1,0 0,0,1
<uvos>
whats that?
<uvos>
when dose this appear
<Wizzup>
is that the identity you mean?
<uvos>
yeah ofc the 3x3 identity matrix
<uvos>
what you wrote is wrong
<uvos>
you have to manny 0
<uvos>
no nvm
<uvos>
its correct
dgamer69 has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
<Wizzup>
uvos: map to output does that
<Wizzup>
(as well)
Guest3 has joined #maemo-leste
<buZz>
hi Guest3
<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!
<Wizzup>
I think the beta is at least a few months out, probably jan 2021 or so?
<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
<Wizzup>
(1) I am working on now, (2) and (3) are more vague but progress has been made
<Wizzup>
and I think currently the n900 touch might be broken on all devices, so I have check what's up with that :)
<Wizzup>
uvos: regarding ^ any idea what could cause this?
<Wizzup>
Guest3: anyway it might still be too optimistic, we seem to hit problems everywhere we go, so everything takes time ;)
dgamer69 has quit [Ping timeout: 265 seconds]
<Wizzup>
uvos: some libinput vs evdev thing maybe?
<Guest3>
I wish you good luck guys! I've been following the project for a long time! I root for you very much!
Guest3 has quit [Quit: Client closed]
<Wizzup>
:)
dgamer69 has joined #maemo-leste
xmn has joined #maemo-leste
<uvos>
Wizzup: no
<uvos>
its proubly the omap ddx being broken
<uvos>
gimmy xrandr output
<Wizzup>
but it wasn't a problem with the rotation script
<uvos>
because we never installed the script on the n900
<Wizzup>
ah.
<Wizzup>
# xrandr
<Wizzup>
Screen 0: minimum 800 x 480, current 800 x 480, maximum 800 x 480
<Wizzup>
LCD connected primary (normal left inverted right x axis y axis) 800x480 6020.32 +
<Wizzup>
TV unknown connection (normal left inverted right x axis y axis) 800x480 6020.32 + 480x800 6020.32
<uvos>
i have had this problem with the omap ddx before
<uvos>
"I think the beta is at least a few months out, probably jan 2021 or so" heh
<Wizzup>
uvos: what do you think? :p
<uvos>
i think its october 2021 allready
<uvos>
but ymmv
<uvos>
i also think jan 2022 is optimistic
<Wizzup>
uvos: possible yeah
<uvos>
so plugg detection is with asoc-audio-graph-card is impossible
<uvos>
the only way it can work is if the plug is on a gpio see asoc_simple_init_jack
<uvos>
tmlind: ^^^^
<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
<uvos>
also the generic asoc drivers are terribly documented (that is not documented at all)
<uvos>
so that royaly sucks
<tmlind>
heh
<uvos>
tmlind: any ideas?
<tmlind>
uvos: keep top level asoc driver generic, add more generic or custom child devices to it?
<tmlind>
that's what might help with the voice calls
<tmlind>
as linux knows nothing about it really
<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?
<uvos>
tmlind: not sure how to approch that
<uvos>
let me explain the current dilemma:
<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
<uvos>
so far so good
_inky has quit [Ping timeout: 245 seconds]
<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.
<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
<uvos>
the codec then uses this jack to report its plug state
<uvos>
but since asoc-audio-graph-card dosent do this im in bind
<uvos>
i could go a head and create another snd_soc_card just to report the jack
<uvos>
but then pulse would not know where to apply the route to
<uvos>
so i really dont see any way forward other than to fork asoc-audio-graph-card to call set_jack on its componants
<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?
<uvos>
but that becomes really messy
<tmlind>
right..
<uvos>
because it shares all the componant handling with snd-soc-simple-card
<uvos>
so i would also have to fork snd-soc-simple-card-utils with it
<uvos>
not great
<tmlind>
yup
<tmlind>
so before heading for a custom codec driver, the voice call stuff we should be able to deal with a separate child device
<tmlind>
right now the voice call codec is a child of mcbsp, while it really should be a child of the cpcap audio driver
<uvos>
yeah
<tmlind>
that should solve the voice mixer issues
<uvos>
i helps when it dosent get powerd off when there is no audio on mcbsp
<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
<tmlind>
so is there some gpio specified for the audio-graph-card binding for set_jack?
dgamer69 has quit [Ping timeout: 265 seconds]
<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
_inky has joined #maemo-leste
<tmlind>
maybe export a notifier function from audio-graph-card that the codec can call?
<uvos>
i gues but that seams like reimplmenting what set_jack seams to be for anywhays
<uvos>
also i was hoping to not add api to audio-graph-card
<tmlind>
heh
<uvos>
considering my merge sucess so far
<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?
<tmlind>
sounds like set_jack would be a nice generic feature to add..
<uvos>
hmm not sure if i understand, if audio-graph-card called set_jack on the codec
<uvos>
the rest would just be in the codec
<tmlind>
i guess i don't follow where you need to call set_jack from..
<uvos>
as it would just call snd_soc_jack_report on the jack it got
<uvos>
from the codec
<uvos>
the codec owns the jack
<tmlind>
ok
<uvos>
er from the card
<uvos>
i mean
<uvos>
the card ie audio-graph-card owns a jack
<tmlind>
ok
<uvos>
and we need the jack in the codec
<uvos>
and set_jack gives the codec a jack to use
<uvos>
but audio-graph-card dosent use it
<tmlind>
maybe you can add something to find jack
<uvos>
there is no api in the snd_soc framework to get a previously registerd jack from a snd_soc_card
<uvos>
so no dosent look like thats possible
<uvos>
with out going and pulling it via private api :P
<tmlind>
yeah kuninori morimoto might have some good ideas there though
<tmlind>
sleepy time here now, ttyl
<uvos>
ttyl
<Wizzup>
uvos: is this new h-d already in non-devel btw?
<Wizzup>
(with the touch screen problems on the n900)
<uvos>
Wizzup: no
<uvos>
did you stepp it with gdb
<uvos>
im pretty sure omap ddx's flaky reporting of the display size is the problem
<uvos>
either way there is likely something wrong on the n900 side consierding xinput is broken too
<Wizzup>
do you mean map-to-output?
<Wizzup>
yeah
<uvos>
yeah
<uvos>
step through xinput map-to-output with gdb especcaly what happens in set_transformation_matrix
<uvos>
that function i just copyed from xinput
<uvos>
and clearly the parameters it calculates are just 0
<uvos>
so some input must be 0 too
<uvos>
you can also trace hildon if you like instead
<uvos>
dosent matter same code
<Wizzup>
I'll file a bug report and look at later, there's too much going on :)