**** BEGIN LOGGING AT Fri Dec 23 03:00:00 2016
Dec 23 07:57:47 <sixwheeledbeast> Maybe would have been better to pawn your leg, at least you have another one...
Dec 23 07:58:00 <bencoh> :/
Dec 23 07:58:13 <KotCzarny> i think he left already
Dec 23 07:58:44 <KotCzarny> but friggin taxi driver stealing n900? the hell with the world we live in
Dec 23 07:59:11 <xes> someone was a bit drunken...or both of them
Dec 23 09:22:12 <DocScrutinizer05> http://neo900.org/stuff/joerg/ECI/all_buttons/
Dec 23 09:27:31 <DocScrutinizer05> for N900 bitbang outbound data with SoC TVOUT_EN while TVOUT set to GPIO-OUT:GND/low
Dec 23 09:31:42 <DocScrutinizer05> to read inbound, use ECI_AD and/or comparator N4008:ECI1:GPMC_nWP-H1 and/or N4007:ECI0:GPMC_nBE1-H3
Dec 23 09:32:45 <DocScrutinizer05> particularly the latter seems very suited
Dec 23 09:34:12 <DocScrutinizer05> prolly already also used to detect holdbutton-press
Dec 23 09:34:34 <DocScrutinizer05> ECI is basically just holdbutton fast morse ;-)
Dec 23 09:37:02 <DocScrutinizer05> such software solution will be 100% compatible to Neo900 too
Dec 23 09:40:18 <DocScrutinizer05> for implementation details: you need a kernel IRQ handler listening to interrupts (rising and falling edge) on GPMC_nBE1 pon H3, and push timestamps to a stack for a worker thread to analyze and decode them, and convert them to data (I'm guessing now) available via /dev/ECI and kevent
Dec 23 09:41:04 <DocScrutinizer05> for TX a realtime scheduled userland task might do
Dec 23 09:42:58 <DocScrutinizer05> the ECI phone TX bursts are not time critical re their starting point, and they have a relatively short duration during which the userland task can hog the CPU completely to avoid intra-burst timing getting messed up by scheduler task switching
Dec 23 09:44:05 <DocScrutinizer05> and even when a higher prio system interrupt will eventually mess up a burst, nothing too bad will happen
Dec 23 09:44:39 <DocScrutinizer05> just make sure to disable your own RX IRQs during TX ;-)
Dec 23 09:45:24 <DocScrutinizer05> well, for TWOUT_EN they won't even fire on hw level, so that's no issue
Dec 23 09:45:32 <DocScrutinizer05> TV*
Dec 23 09:46:19 <DocScrutinizer05> bota bene: without proper initialization a ECI headset will "act dead"
Dec 23 09:46:46 <DocScrutinizer05> nota, even
Dec 23 09:47:10 <DocScrutinizer05> atk: ^^^ how about that? ;-)
Dec 23 09:47:50 <DocScrutinizer05> Pali: you also might be mildly interested
Dec 23 09:48:38 <DocScrutinizer05> Pali: except for the "PHY layer" the solution is pretty platform agnostic
Dec 23 09:50:15 <DocScrutinizer05> TV_OUT controls MICBIAS *fast*, and GPMC_nBE1-H3 is any generic input that can cause an IRQ on HS mic ring MICBIAS getting pulled to GND (and ideally also on returning from GND to level)
Dec 23 09:50:51 <DocScrutinizer05> worst case you can emulate the latter via ALSA record ;-)
Dec 23 10:08:49 <DocScrutinizer05> s/ TV_OUT / TVOUT_EN / 2 above
Dec 23 10:12:23 <DocScrutinizer05> hint: TVOUT_EN = GPIO40
Dec 23 10:27:04 <DocScrutinizer05> http://neo900.org/stuff/joerg/ECI/scopeshots/ECI_NOT__N900_plugin_for_reference.jpg
Dec 23 10:54:27 <atk> DocScrutinizer05: https://lwn.net/Articles/420775/
Dec 23 10:55:38 <DocScrutinizer05> well, that's age old and may be very useful to 'RE' the high level details of ECI, but it's based on a dedicated NCU for controlling the PHY access to the mic line
Dec 23 10:55:38 <atk> DocScrutinizer05: if anything, that can be used as a base, I'll try to work out why it was never accepted
Dec 23 10:55:58 <atk> I see
Dec 23 10:58:22 <DocScrutinizer05> so when you see e.g http://neo900.org/stuff/joerg/ECI/scopeshots/ECIbackbuttonpress.jpg in my tests, in that sourcecode you may see something like ECI_write_2bytes(0b00100000, 0b00000000)
Dec 23 10:59:38 <atk> It's weird, when I google "ECI" or "Enhancement Control Interface" I get nothing relevantz
Dec 23 11:00:16 <atk> s/z$//
Dec 23 11:00:26 <DocScrutinizer05> well, except this is a screenshot of a HS reply, so you rather see a ECIread() == 0b00100000; ECIread() == 0b00000000;
Dec 23 11:00:50 <atk> I see
Dec 23 11:01:03 <DocScrutinizer05> yeah, there is *very* little publicly available docs anout ECI
Dec 23 11:01:32 <atk> So these inline controls in earphones actually have logic in them?
Dec 23 11:01:45 <DocScrutinizer05> yes
Dec 23 11:02:44 <atk> and it's a two way protocol? This seems like a lot of work just to reuse legacy 3.5mm jacks for data transfer :P
Dec 23 11:02:56 <DocScrutinizer05> yes, single wire bidir serial
Dec 23 11:04:01 <DocScrutinizer05> well, they use the same for e.g SIM data, for battery embedded gas gauges (bq27000, HDQ protocol) and whatnot else
Dec 23 11:04:30 <atk> So I can get my hands on a headset pretty easily, and can probably work some things out from that kernel driver, I presume I'd need to get one of those extremely rare beagle bone boards to do the software side of the deal on?
Dec 23 11:05:01 <DocScrutinizer05> actually SIM SWP is even way more complex since it uses two independent channels on one wire: master mudulates volatge while concurrently slave modulates current
Dec 23 11:05:29 <DocScrutinizer05> don't you have a N900?
Dec 23 11:06:02 <DocScrutinizer05> a N900 will work excellent for this
Dec 23 11:06:16 <DocScrutinizer05> while on BeagleBoard the hardware is missing
Dec 23 11:06:44 <atk> I see
Dec 23 11:06:54 <atk> so N900 does this in software too?
Dec 23 11:06:58 <DocScrutinizer05> ~schematics
Dec 23 11:06:58 <infobot> i heard schematics is http://wiki.maemo.org/N900_Hardware_Schematic
Dec 23 11:07:15 <DocScrutinizer05> N900 doesn't do this so far, that's the point
Dec 23 11:07:17 <DocScrutinizer05> :-)
Dec 23 11:07:30 <DocScrutinizer05> it *could* do it with the right software
Dec 23 11:08:04 <atk> Ah, cool
Dec 23 11:08:38 <DocScrutinizer05> my tests are done with a N97-mini and a genuine (inknown type) Nokia multibutton headset
Dec 23 11:11:54 <atk> My scope should also be able to manage this too. So I just need a headset and then work out how to deal with that part of the kernel :P Should be fun.
Dec 23 11:12:05 <DocScrutinizer05> ~literal schematics
Dec 23 11:12:05 <infobot> "schematics" is "http://wiki.maemo.org/N900_Hardware_Schematic"
Dec 23 11:12:17 <DocScrutinizer05> ~schematics is also http://www.google.de/search?q=nokia+n900+rx-51+schematics.pdf&oq=Nokia_N900_RX-51_schematics
Dec 23 11:12:17 <infobot> okay, DocScrutinizer05
Dec 23 11:13:29 <DocScrutinizer05> http://wstaw.org/m/2016/12/23/plasma-desktopN17764.png
Dec 23 11:15:02 <DocScrutinizer05> http://maemo.cloud-7.de/share-service/20161222_002.jpg my test setup
Dec 23 11:15:52 <DocScrutinizer05> (without scope probe attached yet, goes to the yellow clip)
Dec 23 11:17:00 <DocScrutinizer05> note how you can tell apart pulses sent by HS from pulses sent by phone, by the different "GND" level which is lower for the HS pulses
Dec 23 11:19:16 <DocScrutinizer05> http://neo900.org/stuff/joerg/ECI/scopeshots/ECIpulseHS.jpg  http://neo900.org/stuff/joerg/ECI/scopeshots/ECIpulsePhone.jpg  http://neo900.org/stuff/joerg/ECI/scopeshots/ECIplugin_init.jpg
Dec 23 11:21:13 <DocScrutinizer05> http://neo900.org/stuff/joerg/ECI/init/ECI_init00.png http://neo900.org/stuff/joerg/ECI/init/ECI_init01_ph4ms_low_hsA2pulses.jpg
Dec 23 11:21:55 <DocScrutinizer05> note how in the latter the two short pulses after the 4ms intitial one are from HS, they are lower voltage
Dec 23 11:23:15 <DocScrutinizer05> and have that tiny "mark" on beginning of falling edge: http://wstaw.org/m/2016/12/23/plasma-desktopc17764.png
Dec 23 11:23:52 <DocScrutinizer05> which in fact is the initial slight voltage drop to be seen in http://neo900.org/stuff/joerg/ECI/scopeshots/ECIpulseHS.jpg
Dec 23 11:28:11 <DocScrutinizer05> your first task would be to find the "IDENTIFY-YOURSELF" command the phone sends at very beginning of a headset plugged in, in the existing ECI, and compare to http://neo900.org/stuff/joerg/ECI/init/ECI_init02_phCMD_identify.jpg to deduce the actual bit coding and byte frame (AIUI one startbit(1), and a stop-startbit separator(01) only on multibyte bursts)
Dec 23 11:29:24 <DocScrutinizer05> the sigle bit seems to be encoded as either 1 low 4 high (unit 100us?) or 4 low 1 high
Dec 23 11:30:37 <DocScrutinizer05> err sorry, rather it's 4h1l  or 1h4l
Dec 23 11:30:59 <DocScrutinizer05> startbit is 4h1l it seems
Dec 23 11:31:27 <DocScrutinizer05> you don't see the leading 4h since the line is h all the time when inactive
Dec 23 11:33:08 <DocScrutinizer05> when sending 2 bytes, I seem to see a 4l1h stop bit at end of first byte, and the usual 4h1l start bit following it. then the second 8 bit follow
Dec 23 11:42:26 <DocScrutinizer05> even though this http://neo900.org/stuff/joerg/ECI/init/ECI_init02_phCMD_identify.jpg looks to me like startbit(1) [data]00001111   >>WHATSTHIS???(1timeunit-h,1timeunit-l)=startbit_with shirt-hightime?(1)<<  [data]00000000  <finish>; so has NO stopbit
Dec 23 11:43:55 <DocScrutinizer05> I'd expect you find a "IDENTIFY" (owtte) command in the existing ECI sources, of a value like 0x0f00 or 0xf0ff
Dec 23 11:46:43 <DocScrutinizer05> oops sorry, I slipped
Dec 23 11:48:01 <DocScrutinizer05> startbit(1) [data]00001111   >>WHATSTHIS???(1timeunit-h,1timeunit-l)=startbit_with shirt-hightime?(1)<<  [data]01011010  <finish>
Dec 23 11:50:11 <DocScrutinizer05> so a value like 0x0f5a or 0xf0a5
Dec 23 11:53:20 <DocScrutinizer05> let's define startbit=100us-high + 100us-low; bit1= 400us-high + 100us-low; bit0= 100us-high + 400us-low  --- just as a working hypothesis
Dec 23 11:54:19 <DocScrutinizer05> and data frame format = 1 startbit, 8 data bits, no stop bit
Dec 23 11:56:39 <DocScrutinizer05> hmm, make that 80us and 320us
Dec 23 11:57:04 <DocScrutinizer05> doesn't matter I guess. And easy to tune in source later on
Dec 23 12:02:34 <DocScrutinizer05> anyway, to send out a pulse, you toggle the TVOUT_EN pin for the duration of the low-pulse you want to send (while making sure TVOUT is low, this shouldn't be a problem I hope. should be default as long as TV not enabled). Inbound data you receive on ECI0 aka GPMC_nBE1 pin H3 (I think it's already there somewhere as either ECI0 or ECI1 sys or dev node, however you rather want a IRQ kernel handler on it)
Dec 23 12:03:44 <DocScrutinizer05> IroN900:~# find /sys -iname '*eci*'
Dec 23 12:03:46 <DocScrutinizer05> /sys/devices/platform/nokia-av/eci0
Dec 23 12:03:47 <DocScrutinizer05> /sys/devices/platform/nokia-av/eci1
Dec 23 12:03:49 <DocScrutinizer05> /sys/devices/platform/soc-audio/eci_mode
Dec 23 12:08:28 <DocScrutinizer05> eci0 and 1 are read-only, so I guess they must be the inputs for the two comparators N4007 and N4008, which conveniently connect to ECI0 and ECI1 in schematics too ;-)
Dec 23 12:08:50 <DocScrutinizer05> so what you want to read is /sys/devices/platform/nokia-av/eci1
Dec 23 12:09:08 <DocScrutinizer05> or rather monitor with your IRQ handler
Dec 23 12:10:01 <DocScrutinizer05> of course for a mere POC you could also poll with a period of 80us
Dec 23 12:11:16 <DocScrutinizer05> hmm, prolly rather 50us
Dec 23 12:18:07 <DocScrutinizer05> IroN900:/sys/devices/platform/nokia-av# time (for (( i=0; i<40; i++ )); do cat eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0 eci0; done >/dev/null)
Dec 23 12:18:08 <DocScrutinizer05> real    0m0.593s
Dec 23 12:20:06 <DocScrutinizer05> so this thing already polls @ 70us
Dec 23 12:20:50 <DocScrutinizer05> should be able to read out a HS response raw data (to a real file instead of /dev/null)
Dec 23 12:22:26 <DocScrutinizer05> I'm pretty sure you can optimize the overhead quite a lot, though in the end you do _not_ want to poll if this shall be a useful thing
Dec 23 12:30:38 <DocScrutinizer05> IroN900:/sys/devices/platform/nokia-av# time (for (( i=0; i<1000; i++ )); do read r <eci0; echo -n "$r:"; done >/dev/null)
Dec 23 12:30:40 <DocScrutinizer05> real    0m0.546s
Dec 23 12:53:16 <Pali> here is source code of nokia-av driver from stock nokia n900 kernel: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c
Dec 23 12:56:33 <Pali> and here is rx51_set_eci_mode function: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/sound/soc/omap/rx51.c#L175
Dec 23 12:57:28 <Pali> so it change RX51_ECI_SWITCH_1_GPIO and RX51_ECI_SWITCH_2_GPIO gpios
Dec 23 12:57:36 <Pali> #define RX51_ECI_SWITCH_1_GPIO		178
Dec 23 12:57:41 <Pali> #define RX51_ECI_SWITCH_2_GPIO		182
Dec 23 13:02:29 <DocScrutinizer05> looks good. while my tests with `` IroN900:/sys/devices/platform/nokia-av# while :; do for f in eci0 eci1 detect type /sys/devices/platform/soc-audio/eci_mode madc; do echo -n "$f:`cat $f`  "; done;echo;done ´´ yield very puzzling results - I suspect mce-or-whatever interferes
Dec 23 13:04:20 <DocScrutinizer05> puzzling results are: ECI0 always "0" while detect goes "4" -> "2" when pressing the hold button
Dec 23 13:04:47 <DocScrutinizer05> and even madc is always at around 4 or 5
Dec 23 13:05:18 <DocScrutinizer05> I already thought my headset was defect until I noticed the detect value change
Dec 23 13:05:51 <Pali> no, nobody in Maemo is doing anything with eci_mode sysyfs
Dec 23 13:05:58 <Pali> at least not in stock PR1.3
Dec 23 13:06:22 <DocScrutinizer05> then those nodes provide not at all what their names suggest
Dec 23 13:06:29 <Pali> grepped rootfs of PR1.3 /mnt/n900/{bin,lib,sbin,usr/lib,usr/bin,usr/sbin}
Dec 23 13:07:29 <DocScrutinizer05> madc=4 means what? a 100mV on micbias?
Dec 23 13:08:16 <Pali> ADCIN4 - Battery size indicator
Dec 23 13:08:25 <DocScrutinizer05> and even if that was true, how the heck does "detect" notice holdbutton press while madc doesn't change value?
Dec 23 13:08:57 <DocScrutinizer05> not ADCIN4
Dec 23 13:09:23 <DocScrutinizer05> /sys/devices/platform/nokia-av/madc
Dec 23 13:09:25 <Pali> look: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L280
Dec 23 13:09:42 <DocScrutinizer05> value = 4
Dec 23 13:10:44 <Pali> that madc sysfs returns value fomr ADCIN2
Dec 23 13:10:49 <Pali> ADCIN2 - ECI AD
Dec 23 13:11:06 <Pali> and that value = 4 is RAW value
Dec 23 13:11:28 <Pali> mV = RAW * 147 / 60
Dec 23 13:13:08 <DocScrutinizer05> ~4*147/50
Dec 23 13:13:08 <infobot> 11.76
Dec 23 13:13:15 <Pali> so it is 9.8mV
Dec 23 13:13:22 <Pali> ~4*147/60
Dec 23 13:13:22 <infobot> 9.8
Dec 23 13:13:23 <DocScrutinizer05> doesn't make sense
Dec 23 13:14:05 <DocScrutinizer05> madc is always 4 or 5 no matter if I push holdbutton or not
Dec 23 13:15:33 <DocScrutinizer05> so whatever `cat /sys/devices/platform/nokia-av/madc` shows, it's quite evidently not the voltage on mic line of AV jack
Dec 23 13:17:04 <Pali> do you have mic bias enabled?
Dec 23 13:17:24 <DocScrutinizer05> use my cmdline, see for yourself! :: cd /sys/devices/platform/nokia-av; while :; do for f in eci0 eci1 detect type /sys/devices/platform/soc-audio/eci_mode madc; do echo -n "$f:`cat $f`  "; done;echo;done
Dec 23 13:17:29 <Pali> because alsaped maemo daemon is automatically disabling it when headset is plugged
Dec 23 13:17:37 <Pali> ok, going to test
Dec 23 13:17:51 <DocScrutinizer05> Pali: it detects holdbutton press, and holdbutton shorts micbias to GND
Dec 23 13:18:35 <DocScrutinizer05> so yes, obviously (and according to http://neo900.org/stuff/joerg/ECI/scopeshots/ECI_NOT__N900_plugin_for_reference.jpg) my MICBIAS is enabled
Dec 23 13:19:31 <DocScrutinizer05> http://paste.opensuse.org/40688624
Dec 23 13:20:57 <DocScrutinizer05> stock kernel here!
Dec 23 13:21:10 <DocScrutinizer05> with CSSU
Dec 23 13:23:12 <DocScrutinizer05> the invincible rationale being: when holdbutton press gets detected (see value of "detect" 4->2) then the value of madc *must* go down from a high value to maybe 4 or 5, if madc shows the voltage of micbias
Dec 23 13:24:10 <DocScrutinizer05> madc not changing at all while value of detect changes with holdbutton status indicated madc is bogus
Dec 23 13:25:37 <DocScrutinizer05> I'd also expect eci0 to be 1 as long as hold button not pressed. It's always 0
Dec 23 13:26:09 <DocScrutinizer05> conclusion: kernel driver fubar
Dec 23 13:26:49 <DocScrutinizer05> eci is 1 as long as no hs plugged at all
Dec 23 13:27:16 <DocScrutinizer05> sth is fuxored there
Dec 23 13:31:15 <Pali> madc here is about 68
Dec 23 13:31:15 <DocScrutinizer05> ohmmy! I guess I know what's happening. I suspect `cat detect` enables micbias, checks button status, and disables micbias again
Dec 23 13:31:28 <Pali> and sometimes when I push button then madc is 135
Dec 23 13:31:31 <Pali> but just sometimes
Dec 23 13:32:14 <DocScrutinizer05> I wondered why the cmdline takes that looooong
Dec 23 13:32:17 <Pali> and if I start pressing button to quick madc goes above 210
Dec 23 13:32:26 <DocScrutinizer05> o.O
Dec 23 13:32:38 <DocScrutinizer05> that's not ok for sure
Dec 23 13:32:56 <KotCzarny> some counter?
Dec 23 13:33:02 <Pali> see what is cat detect doing: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L280
Dec 23 13:33:12 <Pali> it changes those GPIOs
Dec 23 13:33:12 <DocScrutinizer05> with headset unplugged, my madc is at 1024 around
Dec 23 13:33:20 <KotCzarny> check if it changes with the rate you are pressing
Dec 23 13:34:40 <DocScrutinizer05> Pali: so quite possibly my micbias is NOT enabled all the time
Dec 23 13:35:05 <DocScrutinizer05> Pali: and it seems yours isn't as stable as it's supposed to be, as well
Dec 23 13:35:37 <DocScrutinizer05> the dependency on push speed is from R-C charging of micbias voltage buffer cap
Dec 23 13:36:15 <Pali> bah!! cat detect disable mic bias
Dec 23 13:36:18 <Pali> see alsamixer -c 0
Dec 23 13:36:19 <DocScrutinizer05> something's totally messed up in there
Dec 23 13:36:58 <DocScrutinizer05> yes, see what I said above: obviously cat detect enables micbias to run the tests and then disables it again
Dec 23 13:37:15 <Pali> now when mic bias is always enabled, then madc is about 317
Dec 23 13:37:32 <Pali> and when I press button it is about 68
Dec 23 13:37:40 <DocScrutinizer05> now that makes sense :-)
Dec 23 13:38:05 <DocScrutinizer05> how would I enable micbias?
Dec 23 13:38:12 <Pali> alsamixer -c 0
Dec 23 13:38:15 <DocScrutinizer05> ta
Dec 23 13:38:17 <Pali> and find "jack bias"
Dec 23 13:38:25 <Pali> and use 'm' key
Dec 23 13:38:34 <Pali> to switch between on/off
Dec 23 13:39:19 <KotCzarny> oscp uses micbias to detect button presses on nokia headsets
Dec 23 13:39:39 <KotCzarny> s/micbias/jack bias/
Dec 23 13:39:40 <infobot> KotCzarny meant: oscp uses jack bias to detect button presses on nokia headsets
Dec 23 13:39:43 <DocScrutinizer05> amixer -c 0 scontrols|grep -i bias
Dec 23 13:40:31 <Pali> looks like nobody in maemo is accessing /sys/devices/platform/nokia-av/detect
Dec 23 13:40:57 <Pali> (only /usr/lib/testserver/modules/handlers/selftests.so.0)
Dec 23 13:41:15 <Pali> (but whole testserver is irrelevant there as it is not running in normal Maemo)
Dec 23 13:41:54 <Pali> ~65*147/60
Dec 23 13:41:54 <infobot> 159.25
Dec 23 13:42:06 <Pali> ~317*147/60
Dec 23 13:42:06 <infobot> 776.65
Dec 23 13:42:24 <Pali> hm... so 160mV and 780mV?
Dec 23 13:44:23 <DocScrutinizer05> amixer -c 0 cset name='Jack Bias Switch' 1
Dec 23 13:45:18 <Pali> yes
Dec 23 13:45:33 <DocScrutinizer05> http://paste.opensuse.org/38383984
Dec 23 13:45:55 <Pali> anyway, CSSU in some version automatically enable jack bias after inserting headset with mic
Dec 23 13:47:57 <DocScrutinizer05> DAMMIT! phonecall, no audio. I guess it tried to use a headset thats not there
Dec 23 13:48:06 <DocScrutinizer05> :-/
Dec 23 13:48:54 <DocScrutinizer05> I should start to use a test device for such experiments again
Dec 23 14:15:13 <DocScrutinizer05> Pali: do you know what autodetect sysnode does?
Dec 23 14:15:32 <DocScrutinizer05> in /sys/devices/platform/nokia-av/autodetect
Dec 23 14:17:25 <Pali> yes, it just control variable autodetect
Dec 23 14:17:33 <Pali> and that is used only here: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L456
Dec 23 14:17:47 <Pali> when set to zero then that headph_handler is noop
Dec 23 14:19:38 <DocScrutinizer05> HAH! after boot, with hs plugged in:  eci0:1  eci1:1  detect:3  type:2  /sys/devices/platform/soc-audio/eci_mode:1  madc:1023 
Dec 23 14:20:55 <Pali> I updated https://wiki.maemo.org/Porting/Kernel#Porting
Dec 23 14:21:18 <Pali> now cssu can boot without /proc/bootreason and /dev/twl4030-adc
Dec 23 14:22:32 <DocScrutinizer05> plug-cycled, NOW we're talking! :) http://paste.opensuse.org/83643851
Dec 23 14:23:37 <DocScrutinizer05> Pali: (cssu) excellent, that stuff is pretty much pointless, particularly the twl4030-adc for BSI test battery
Dec 23 14:24:39 <Pali> we need to also get rid off /proc/component_version and /sys/class/gpio-swich
Dec 23 14:24:44 <DocScrutinizer05> I *guess* bootreason makes some sense for deciding if to re-use an existing PIN or ask for it again
Dec 23 14:25:21 <Pali> I mean, maemo cssu can boot without those files
Dec 23 14:25:34 <Pali> if files are provided they are used
Dec 23 14:25:53 <DocScrutinizer05> meh /proc/component_version
Dec 23 14:26:05 <DocScrutinizer05> what the heck?!
Dec 23 14:26:05 <Pali> if not, then fallback mechanism is used (e.g. /proc/cpuinfo or /proc/atags) or hardcoded strings, eg. bootreason is pwr_key
Dec 23 14:26:22 <DocScrutinizer05> compiled in to kernel (DT?)
Dec 23 14:26:26 <Pali> component version is key/value file
Dec 23 14:26:31 <Pali> with data from NOLO
Dec 23 14:26:35 <Pali> passed via ATAGs
Dec 23 14:26:36 <DocScrutinizer05> ohmy
Dec 23 14:27:03 <DocScrutinizer05> ATAGs my headache
Dec 23 14:27:11 <Pali> and nolo pass just: board name, hw revision, nolo version and boot mode
Dec 23 14:27:31 <Pali> and boot mode is either "normal" or "update"
Dec 23 14:27:48 <Pali> and some rcS script check for "update" and enter into different runlevel
Dec 23 14:27:49 <DocScrutinizer05> I wonder how hard it could get to completely replace NOLO by uboot
Dec 23 14:28:01 <Pali> when just softup via usb is running
Dec 23 14:28:10 <Pali> already tried to replace NOLO with uboot
Dec 23 14:28:15 <Pali> and I failed
Dec 23 14:28:22 <DocScrutinizer05> yeah I know
Dec 23 14:28:27 <DocScrutinizer05> wonder why, though
Dec 23 14:28:31 <Pali> 1. problem is size 100kB
Dec 23 14:28:37 <DocScrutinizer05> ugh
Dec 23 14:28:37 <Pali> uboot is big :-(
Dec 23 14:29:01 <Pali> 2. problem uboot has broken onenand support (or had in ~~ 2012)
Dec 23 14:29:16 <DocScrutinizer05> doubleplusugh
Dec 23 14:29:17 <Pali> 3. problem uboot has broken omap3 usb
Dec 23 14:29:34 <DocScrutinizer05> ohmy
Dec 23 14:30:13 <Pali> 4. problem no idea which hw initialization is needed to implement
Dec 23 14:30:30 <DocScrutinizer05> sounds nasty
Dec 23 14:30:47 <Pali> we have no idea what it is doing... probably some SSI/modem init is needed too...
Dec 23 14:31:04 <DocScrutinizer05> isn't there a working uboot for pandora and beagleboard?
Dec 23 14:31:27 <DocScrutinizer05> oooh modem init
Dec 23 14:31:28 <Pali> and at that time in uboot was no support for spi... so no display init code
Dec 23 14:31:41 <DocScrutinizer05> ouch
Dec 23 14:31:44 <Pali> pandora and beagleboard is probably working fine with uboot
Dec 23 14:31:53 <Pali> but thse do not have nokia's SSI modem
Dec 23 14:32:00 <DocScrutinizer05> yeah sure
Dec 23 14:32:17 <Pali> uboot is working fine on n900, just it needs to be loaded by nolo :-)
Dec 23 14:32:24 <DocScrutinizer05> but... the modem should get initialized only lated, by kernel
Dec 23 14:32:29 <DocScrutinizer05> later*
Dec 23 14:32:37 <KotCzarny> glue uboot to nolo
Dec 23 14:32:43 <KotCzarny> or nolo to uboot
Dec 23 14:32:59 <Pali> nolo can flash fw for modem...
Dec 23 14:33:07 <Pali> so there is big blob in nolo for that
Dec 23 14:33:15 <DocScrutinizer05> eeek
Dec 23 14:33:16 <Pali> and no idea if some init is really not needed...
Dec 23 14:33:30 <Pali> KotCzarny: see first problem about size
Dec 23 14:33:35 <DocScrutinizer05> are you sure modem flashing done by nolo?
Dec 23 14:33:49 <Pali> either by nolo or via some RPC
Dec 23 14:34:15 <DocScrutinizer05> I thought it's done along softupd foo
Dec 23 14:34:32 <Pali> softupd can do that
Dec 23 14:34:36 <Pali> but nolo too!
Dec 23 14:34:46 <DocScrutinizer05> incredible
Dec 23 14:34:53 <Pali> and via usb cable to flasher-3.5 nolo exports some strange protocol for modem flashing status
Dec 23 14:35:08 <DocScrutinizer05> I see
Dec 23 14:35:10 <Pali> which is different from other notification
Dec 23 14:35:24 <DocScrutinizer05> yep, of course. It's Nokia shit
Dec 23 14:35:42 <Pali> every status information to flasher-3.5 has one format, just modem flashing status has different
Dec 23 14:35:43 <DocScrutinizer05> F-Bus
Dec 23 14:35:58 <Pali> it is string based (for flasher-3.5)
Dec 23 14:36:12 <Pali> but some f-bus is probably used in nolo and softupd
Dec 23 14:36:46 <DocScrutinizer05> this? http://shodhganga.inflibnet.ac.in/bitstream/10603/64948/9/09_chapter 3.pdf
Dec 23 14:38:23 <DocScrutinizer05> possibly for flashing even M-Bus, not F-Bus
Dec 23 14:39:13 <Pali> going to look at that protocol
Dec 23 14:39:19 <DocScrutinizer05> http://mennucc1.debian.net/lacie_network_space/nokia-ca-42/Embedtronics - Nokia F-Bus Protocol made simple.html
Dec 23 14:39:23 <Pali> and compare it with what I sniffed and implemented in 0xFFFF
Dec 23 14:41:10 <Pali> no, protocol is totally different
Dec 23 14:41:23 <DocScrutinizer05> http://wiki.gnokii.org/index.php/MBUS_protocol
Dec 23 14:41:51 <DocScrutinizer05> check Phoenix flashers
Dec 23 14:42:19 <DocScrutinizer05> http://www.allmobiletools.net/2014/12/nokia-phoenix-service-software-201415.html
Dec 23 14:42:56 <DocScrutinizer05> sorry for the useless link
Dec 23 14:43:16 <DocScrutinizer05> https://nokiarevolution.com/how-to-flash-your-nokia-device-via-phoenix-usb-dead-flashing/
Dec 23 14:44:09 <DocScrutinizer05> not much info but for sure the right protocol we're looking for
Dec 23 14:44:23 <DocScrutinizer05> *all* nokia phones use that protocol
Dec 23 14:44:41 <Pali> what softupd thing uses different protocool
Dec 23 14:44:56 <DocScrutinizer05> either via serial (M-bus, F-bus, whatever) or via USB with some wrapper protocol aiui
Dec 23 14:45:00 <Pali> see: https://github.com/pali/0xFFFF/blob/master/doc/mkii
Dec 23 14:45:52 <DocScrutinizer05> yeah softupd is not using phoenix protocol, they use something they made up for maemo
Dec 23 14:46:31 <DocScrutinizer05> I however bet they embedded the phoenix protocol into softupd for BB5-modem flashing
Dec 23 14:46:37 <Pali> anyway, phoenix IIRC uses same protocol for n900
Dec 23 14:46:59 <Pali> and it uses that testserver
Dec 23 14:47:11 <DocScrutinizer05> quite possible, yes
Dec 23 14:47:27 <DocScrutinizer05> BSI crap
Dec 23 14:47:42 <DocScrutinizer05> "lab battery"
Dec 23 14:48:41 <Pali> I have some information that FIASCO format is some BB5 format
Dec 23 14:50:05 <DocScrutinizer05> oooh
Dec 23 14:50:44 <DocScrutinizer05> at least that explains CAL
Dec 23 14:51:15 <DocScrutinizer05> CAL looks *very much* like invented for modem "filesystem"
Dec 23 14:52:04 <DocScrutinizer05> and this is what Phoenix modifies for stuff like ALS calibration etc
Dec 23 14:52:27 <Pali> it uses testserver for that
Dec 23 14:52:38 <Pali> and testserver has plugin for als
Dec 23 14:52:40 <DocScrutinizer05> quite possible
Dec 23 14:52:47 <Pali> so this probably access CAL
Dec 23 14:52:57 <Pali> IIRC nolo does not export any access to CAL over usb
Dec 23 14:53:13 <Pali> I already tried to do anything...
Dec 23 14:53:27 <Pali> also no "backup" support seems to be in NOLO
Dec 23 14:59:15 <DocScrutinizer05> yeah, no Nokia phone has that, prolly considered a security feature
Dec 23 15:00:48 <DocScrutinizer05> anyway seems ECI0 is working like supposed, when enabling micbias. So would you know how to control TVOUT_EN?
Dec 23 15:05:02 <Pali> in sound/soc/omap/rx51.c is: #define RX51_TVOUT_SEL_GPIO		40
Dec 23 15:05:11 <Pali> it is this gpio?
Dec 23 15:07:49 <DocScrutinizer05> yes
Dec 23 15:07:58 <Pali> that is exported to alsa
Dec 23 15:08:04 <DocScrutinizer05> ouch
Dec 23 15:08:08 <Pali> RX51_JACK_TVOUT
Dec 23 15:08:23 <DocScrutinizer05> much overhead to toggle itt
Dec 23 15:08:34 <Pali> when rx51_jack_func is RX51_JACK_TVOUT then RX51_TVOUT_SEL_GPIO is set to 1
Dec 23 15:08:38 <Pali> otherwise to 0
Dec 23 15:09:41 <Pali> but should be possible to control it via /sys/class/gpio
Dec 23 15:09:44 <Pali> as any other gpio
Dec 23 15:09:49 <DocScrutinizer05> I want to create 0.8ms pulses on this GPIO
Dec 23 15:10:25 <DocScrutinizer05> err 0.08ms
Dec 23 15:10:56 <DocScrutinizer05> I can poll eci0 with almost 2000/s
Dec 23 15:11:03 <Pali> bah, linux kernel refuse to export it :-(
Dec 23 15:11:46 <Pali> # echo 40 > /sys/class/gpio/export 
Dec 23 15:11:46 <Pali> bash: echo: write error: Device or resource busy
Dec 23 15:12:18 <Pali> probably because that alsa driver already has it for its own
Dec 23 15:12:55 <DocScrutinizer05> yep
Dec 23 15:13:34 <DocScrutinizer05> also I just realized I did a decimal error, 2000/s is factor 10 too slow for ECI still
Dec 23 15:16:01 <DocScrutinizer05> Pali: you looked into the ECI stuff I pstaed a few hours ago?
Dec 23 15:16:06 <DocScrutinizer05> pasted
Dec 23 15:16:44 <DocScrutinizer05> Pali: http://mg.pov.lt/maemo-irclog/latest.log.html#t2016-12-23T11:22:12
Dec 23 15:17:07 <Pali> yes, I have seen it
Dec 23 15:23:41 <DocScrutinizer05> Pali: I assume stuff like (syslog) "kernel: [ 5615.435241] slide (GPIO 71) is now open" is driven by a kernel IRQ handler? how hard would it be to implement that (or something similar, maybe not to syslog but to a sort of netlink or whatever pipe) for eci0?
Dec 23 15:25:30 <Pali> /sys/class/gpio/ already supports it
Dec 23 15:25:35 <Pali> via poll on sysfs
Dec 23 15:25:38 <DocScrutinizer05> wow
Dec 23 15:25:46 <Pali> but that sound driver refuse to do it
Dec 23 15:26:03 <DocScrutinizer05> wait, sorry?
Dec 23 15:26:18 <DocScrutinizer05> you're not referring to eci0 now, do you?
Dec 23 15:26:43 <Pali> I mean that gpio 40 
Dec 23 15:26:51 <Pali> with # echo 40 > /sys/class/gpio/export 
Dec 23 15:26:55 <DocScrutinizer05> aka TVOUT_EN?
Dec 23 15:26:59 <Pali> yes
Dec 23 15:27:03 <DocScrutinizer05> :nod:
Dec 23 15:27:15 <Pali> but that should work for any gpio number
Dec 23 15:27:42 <KotCzarny> some years ago i saw a project using vga card as a fm radio generator
Dec 23 15:27:56 <Pali> [13:57:36] <Pali> #define RX51_ECI_SWITCH_1_GPIO                178
Dec 23 15:27:56 <Pali> [13:57:41] <Pali> #define RX51_ECI_SWITCH_2_GPIO                182
Dec 23 15:28:07 <Pali> those gpios are also owned by sound driver
Dec 23 15:29:53 <DocScrutinizer05> so not exactly trivial to add an IRQ handler listening to that GPIO178 aka eci0, right?
Dec 23 15:30:17 <Pali> looks like not
Dec 23 15:30:34 <Pali> maybe some debug interface could exist...
Dec 23 15:30:48 <DocScrutinizer05> though actually on hw level IRQ is sort of unentangled and orthogonal to GPIO-IN/OUT
Dec 23 15:31:49 <DocScrutinizer05> a process doing i/o via GPIO doesn't need to know or care about an IRQ set up for that GPIO, and vice versa
Dec 23 15:32:15 <DocScrutinizer05> particularly for input
Dec 23 15:43:01 <Pali> some info is there: cat /sys/kernel/debug/gpio
Dec 23 16:08:02 <DocScrutinizer05> o.O !!!   "gpio-61  (eci0                ) in  hi irq-221 edge-both"
Dec 23 16:08:34 <DocScrutinizer05> YES! URQ edge-both, exactly what we need
Dec 23 16:08:41 <DocScrutinizer05> IRQ*
Dec 23 16:11:38 <DocScrutinizer05> in that IRQ handler simply get the current (relative) systime in microsecond precision, the level of the GPIO (low or high) and send both as one line of text to a socket or fifo (depth max 100 lines) of sorts, for some userland process to analyze and conver it to ECI data
Dec 23 16:12:42 <DocScrutinizer05> usually that "userland process" is called worker thread
Dec 23 16:12:58 <DocScrutinizer05> and actually runs in kernel domain still
Dec 23 16:14:54 <DocScrutinizer05> UGH, should be a wakeup IRQ though#
Dec 23 16:15:31 <DocScrutinizer05> irq-221 edge-both wakeup
Dec 23 16:16:51 <Pali> 2.6.28 kernel does not support poll() syscall for gpio :-(
Dec 23 16:17:03 <Pali> https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
Dec 23 16:17:08 <Pali> this is upstream kernel
Dec 23 16:17:11 <Pali> search for /sys/class/gpio/gpioN/
Dec 23 16:17:27 <Pali> this is probably enough for upstream kernel
Dec 23 16:17:34 <Pali> but not for maemo 2.6.28
Dec 23 16:17:58 <DocScrutinizer05> not sure about that "wakeup", it seems a lot of IRQ don't have it while I'd think they would need to. So maybe it's not what I think it is
Dec 23 16:19:09 <DocScrutinizer05> Pali: afaik kernel IRQ handlers should be chainable
Dec 23 16:20:21 <DocScrutinizer05> so when a IRQ-handler A is already registered for IRQ42 and you register a IRQ-handler B for same IRQ42, then the kernel should call *both*, no?
Dec 23 16:20:45 <Pali> but kernel gpio library does not allow it
Dec 23 16:21:39 <DocScrutinizer05> damn!
Dec 23 16:21:54 <DocScrutinizer05> seems it creates a /dev/input device
Dec 23 16:22:33 <DocScrutinizer05> Dec 23 16:05:53 IroN900 kernel: [ 4663.989837] headphone (GPIO 177) is now connected
Dec 23 16:22:35 <DocScrutinizer05> Dec 23 16:05:54 IroN900 kernel: [ 4665.067871] input: headset button as /class/input/input6
Dec 23 16:23:08 <DocScrutinizer05> how 'realtime' could that get?
Dec 23 16:23:51 <DocScrutinizer05> IroN900:/sys/devices/platform/nokia-av# Dec 23 16:05:48 IroN900 kernel: [ 4658.466400] headphone (GPIO 177) is now disconnected
Dec 23 16:23:53 <DocScrutinizer05> Dec 23 16:05:48 IroN900 ke_recv[1548]: device_removed:2695: udi: /org/freedesktop/Hal/devices/computer_logicaldev_input_1
Dec 23 16:23:54 <DocScrutinizer05> Dec 23 16:05:49 IroN900 mce[830]: Error accessing /dev/input/event4 (condition: 16). Ignoring
Dec 23 16:23:56 <DocScrutinizer05> Dec 23 16:05:49 IroN900 mce[830]: Error when reading from /dev/input/event4: No such device
Dec 23 16:24:09 <Pali> hm... that input file is created after inserting headphones...
Dec 23 16:24:15 <DocScrutinizer05> IOW would events in /dev/input/event* have timestamps?
Dec 23 16:24:40 <Pali> I think input events have timestamps
Dec 23 16:24:52 <DocScrutinizer05> then we're already done, no? :-D
Dec 23 16:25:23 <Pali> but that input device reports only one thing
Dec 23 16:25:28 <DocScrutinizer05> unless that input device has "debouncing" or shit
Dec 23 16:25:30 <Pali> when headset button is pressed
Dec 23 16:25:38 <DocScrutinizer05> ARRRRGH!
Dec 23 16:25:39 <Pali> and it reports after 1s
Dec 23 16:25:45 <Pali> useless for now...
Dec 23 16:25:51 <DocScrutinizer05> double-ARRRRGH!
Dec 23 16:26:02 <Pali> see: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L106
Dec 23 16:26:05 <Pali> this is that code
Dec 23 16:27:48 <DocScrutinizer05> I see, it *does* >>"debouncing" or shit<<
Dec 23 16:28:12 <Pali> maybe easier would be to patch nokia-av.c and recompile just nokia-av.ko
Dec 23 16:29:49 <Pali> what all is needed?
Dec 23 16:30:09 <Pali> would not be easier to implement everything in that nokia-av.ko driver?
Dec 23 16:30:21 <DocScrutinizer05> however it seems https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L106 is *exactly* the location where should happen: IRQ handler sends a worker thread a timestamped event, worker thread decodes the timing and converts the raw data into nice bytes, then sends those to /dev/input*
Dec 23 16:30:53 <DocScrutinizer05> yes, exactly what you said while I typed slowly
Dec 23 16:31:35 <DocScrutinizer05> basically what we need is not much different to the debounce function there
Dec 23 16:31:39 <Pali> ok, after we decode it into bytes.. those bytes are then raw ECI protocol?
Dec 23 16:31:48 <DocScrutinizer05> yes
Dec 23 16:32:02 <Pali> ok
Dec 23 16:32:22 <Pali> and switching micbias on/off is other direction?
Dec 23 16:32:30 <DocScrutinizer05> yes
Dec 23 16:32:53 <Pali> hm... so it needs correct timing
Dec 23 16:33:26 <Pali> and is nokia-av.ko initializing ECI? or we need to implement it?
Dec 23 16:33:36 <Pali> I see that nokia-av.ko already is doing with micbias
Dec 23 16:33:41 <Pali> something...
Dec 23 16:34:25 <DocScrutinizer05> correct timing only really relevant intra-byte TX
Dec 23 16:35:00 <DocScrutinizer05> I'd think the ECI protocil high level is really userland lib thing
Dec 23 16:35:37 <DocScrutinizer05> incl initialization
Dec 23 16:36:21 <DocScrutinizer05> no idea how HARM is doing it (or if at all)
Dec 23 16:36:55 <DocScrutinizer05> I *think* N9/HARM knows and speaks ECI
Dec 23 16:37:29 <DocScrutinizer05> they use a hw "UART" in TPS65951 that is absolutely undocumented
Dec 23 16:38:10 <DocScrutinizer05> TI prolly inplemented it into TPS65951 on nokia's special request
Dec 23 16:38:15 <DocScrutinizer05> for N9
Dec 23 16:39:21 <DocScrutinizer05> now if only I hadn't killed my N9, I could test
Dec 23 16:39:40 <DocScrutinizer05> waaait, I should also be able to test it on N950, no?
Dec 23 16:39:55 <Pali> maybe yes
Dec 23 16:42:27 <Pali> I think easy solution would be to add support for poll() syscall on /sys/devices/platform/nokia-av/eci0
Dec 23 16:42:32 <Pali> and /sys/devices/platform/nokia-av/eci1
Dec 23 16:43:31 <Pali> which are needed? both of them?
Dec 23 16:43:51 <DocScrutinizer05> Oh Nokia F U!! N950 is AHJ
Dec 23 16:44:23 <DocScrutinizer05> eci0 is needed
Dec 23 16:44:58 <Pali> eci1 too?
Dec 23 16:45:12 <DocScrutinizer05> it doesn't even detect the headset when I plug it in
Dec 23 16:45:17 <DocScrutinizer05> no
Dec 23 16:45:34 <DocScrutinizer05> eci1 is for detection only
Dec 23 16:46:04 <DocScrutinizer05> not related to ECI protocol
Dec 23 16:46:41 <Pali> hm... I cannot find any eci headset now :-( I have just original nokia n900 headset and then some old nokia headset with pop-in-port (not jack)
Dec 23 16:47:13 <DocScrutinizer05> eci1 goes 0 whenever a jack with a mic impedance < ~8k Ohm gets plugged in
Dec 23 16:48:37 <DocScrutinizer05> oops < 15k
Dec 23 16:50:24 <DocScrutinizer05> http://wstaw.org/m/2016/12/23/plasma-desktopm17764.png 22k/(22k+6k8)=X/(X+4k7)
Dec 23 16:51:13 <DocScrutinizer05> aka X=22k * (4k7/6k8)
Dec 23 16:52:28 <DocScrutinizer05> also note that this only works when ECI5 switches mux to this comparator, and that disconnects micbias and replaces it by the 4k7 to 2V5
Dec 23 16:52:51 <DocScrutinizer05> so a mere detector thing for detection phase after plugin
Dec 23 16:53:55 <DocScrutinizer05> though of arguable value, given we also have madc
Dec 23 16:54:40 <DocScrutinizer05> anyway not needed for ECI protocol
Dec 23 16:56:26 <Vajb> KotCzarny: i checked local auction sites and it seems that t500 and x220 r about the same price 150-300 depending of the seller...
Dec 23 16:56:54 <KotCzarny> x220 is a few gens higher
Dec 23 16:57:07 <KotCzarny> it would be like you were looking for t520 ;)
Dec 23 16:58:44 <Vajb> interesting that they r about the same price then
Dec 23 16:58:56 <KotCzarny> smaller is more expensive
Dec 23 16:59:02 <KotCzarny> usually
Dec 23 16:59:20 <Vajb> x220 is smaller?
Dec 23 16:59:26 <KotCzarny> x series is ultraportable
Dec 23 16:59:42 <KotCzarny> t series is normal work machines
Dec 23 16:59:54 <Vajb> t520 330e
Dec 23 17:00:00 <KotCzarny> forget 330e
Dec 23 17:00:11 <KotCzarny> hehe
Dec 23 17:00:35 <KotCzarny> unless they b0rk the series numbers, but afair it was like that always
Dec 23 17:00:50 <KotCzarny> ie t60/x60, t500/x200
Dec 23 17:01:33 <KotCzarny> i got mine cheap when some company was upgrading from t500 laptops to t540
Dec 23 17:02:25 <Vajb> yes. Im going to check one store which used to sell their old business laptops
Dec 23 17:03:13 <Vajb> last time i visite there were some lenovo machines around 150e. Can't recall the number tho
Dec 23 17:03:17 <Vajb> visited*
Dec 23 17:03:41 <KotCzarny> i bught direct via local classifieds site, 2nd hand stores usually add their markup
Dec 23 17:03:48 <Vajb> e series is low end i suppose?
Dec 23 17:04:01 <KotCzarny> yup, you only want t or x
Dec 23 17:04:18 <KotCzarny> depending if you want screen size or mobility
Dec 23 17:04:37 <KotCzarny> i dont remember if newer x series accomodated for dvd slot
Dec 23 17:04:51 <KotCzarny> but having it you can swap it for 2nd hdd, which is much more useful
Dec 23 17:05:06 <KotCzarny> in that case you want t series (or a dock)
Dec 23 17:05:30 <Vajb> i saw docks for sale for 30e
Dec 23 17:05:47 <KotCzarny> first get a machine
Dec 23 17:06:13 <Vajb> sure
Dec 23 17:06:33 <Vajb> i suppose they come with win7 at least...
Dec 23 17:06:41 <Vajb> i've had it with vista
Dec 23 17:06:46 <KotCzarny> depends, some with vista, some with win7
Dec 23 17:07:04 <KotCzarny> it was a switching period
Dec 23 17:07:13 <Vajb> i c
Dec 23 17:08:46 <Vajb> and well vista eol will be next year anyway
Dec 23 17:09:25 <KotCzarny> you can grab win7_64 boxed version, then install whenever you like
Dec 23 17:09:29 <DocScrutinizer05> DAMN AHJ!! I can swap center pin and sleeve of my AV-cable hookup in my test setup http://maemo.cloud-7.de/share-service/20161222_002.jpg - BUT that doesn't work since the earphones (red and white plug of AV cable) also are connected to sleeve of the 3.5mm jack :-/
Dec 23 17:11:01 <DocScrutinizer05> still I don't get it why it doesn't work
Dec 23 17:11:13 <Vajb> oh t series is 64bit?
Dec 23 17:11:23 <KotCzarny> most core2duos are
Dec 23 17:11:38 <KotCzarny> if not all ;)
Dec 23 17:11:53 <Vajb> i c
Dec 23 17:12:03 <KotCzarny> and you can always change the cpu
Dec 23 17:12:11 <KotCzarny> as its socketed (soldered in x)
Dec 23 17:13:02 <KotCzarny> you should write all those requirements on your check-list
Dec 23 17:13:48 <Vajb> i don't have much requirements :)
Dec 23 17:13:59 <Vajb> i just have to be cheap and snappy
Dec 23 17:14:05 <Vajb> it*
Dec 23 17:14:13 <KotCzarny> add ssd to the list
Dec 23 17:14:35 <Vajb> oh yes that will kill the cheap bit
Dec 23 17:14:45 <KotCzarny> ssd drives are reusable
Dec 23 17:14:57 <KotCzarny> you can always move it from/to
Dec 23 17:15:16 <Vajb> ok i'll make some notes so t or x serie ssd
Dec 23 17:15:46 <KotCzarny> you can get it with hdd and just buy ssd yourself (then move hdd to the bay)
Dec 23 17:15:48 <Vajb> r they all core2duo because i think i saw some sold as i5?
Dec 23 17:16:17 <KotCzarny> t500 are from core2duo era, i think t510 or t520 was the first ones with intel iX
Dec 23 17:16:37 <KotCzarny> http://www.thinkwiki.org/wiki/Category:T_Series
Dec 23 17:16:49 <KotCzarny> yeah, all t500 are core2duo
Dec 23 17:17:01 <KotCzarny> t510 are i5/i7
Dec 23 17:17:08 <Vajb> ah i think they were some others then
Dec 23 17:17:13 <Vajb> ok
Dec 23 17:18:38 <KotCzarny> well, t4xx series are similar to t5xx, but using smaller screen
Dec 23 17:18:48 <KotCzarny> so you might hunt those too
Dec 23 17:18:58 <KotCzarny> (14" vs 15")
Dec 23 17:19:51 <Vajb> ok, no versions with 17"?
Dec 23 17:20:11 <KotCzarny> not in the normal thinkpad series
Dec 23 17:20:51 <Vajb> ok i think i'll go with t series because my laptop just sits on the table always
Dec 23 17:22:59 <Vajb> next week im going to that store and see what they have also im keeping my eye on auction site, but it seems the amount will be about 150e eventually
Dec 23 17:23:22 <KotCzarny> or just be patient and look for it in the nearest 6 months
Dec 23 17:23:32 <KotCzarny> acer still works, so no rush
Dec 23 17:23:42 <Vajb> yup, thx bbl
Dec 23 17:23:51 <KotCzarny> and you can put 10e/month into 'new laptop fund of vajb'
Dec 23 17:24:20 <Vajb> hehe yeah
Dec 23 17:24:39 <Vajb> and acer works but vista not so much
Dec 23 17:24:45 <KotCzarny> go xp?
Dec 23 17:56:41 <KotCzarny> http://www.cnx-software.com/2016/12/23/25-nanopi-a64-is-a-compact-yet-features-packed-allwinner-a64-development-board/
Dec 23 17:56:46 <KotCzarny> um, wrong chan
Dec 23 18:19:40 <Vajb> is xp still supported?
Dec 23 18:20:03 <KotCzarny> i think there was some hack
Dec 23 18:21:34 <Vajb> i'll see if i can find vista disk and try repair
Dec 23 18:22:12 <Vajb> sfc found some weird registry issues
Dec 23 18:22:49 <KotCzarny> viree?
Dec 23 18:27:21 <Vajb> umm come again?
Dec 23 18:27:31 <KotCzarny> virus?
Dec 23 18:27:54 <Vajb> shouldn't be
Dec 23 18:28:50 <Vajb> i've used trendmicro house call + ms antivirus also two scanners for rootkits and three for malware
Dec 23 18:29:20 <KotCzarny> vista + 2 av programs? no wonder its slow as molasses
Dec 23 18:30:01 <Vajb> trendmicro is just online scanner which i use occasionally to get second opinion
Dec 23 18:30:31 <sicelo-> what are you using xp for?
Dec 23 18:31:03 <Vajb> sicelo-: it was just suggestion to replace vista
Dec 23 18:31:22 <Vajb> i have vista which refuses to update itself
Dec 23 18:31:37 <sicelo-> xp won't update at all :)
Dec 23 18:31:54 <KotCzarny> btw. that windows update fail also happens on w7
Dec 23 18:31:58 <Vajb> so problem solved :p
Dec 23 18:31:59 <KotCzarny> it's m$ fault
Dec 23 18:32:37 <Vajb> KotCzarny: yes i know, but there is a tool to fix it from ms. Sadly it is not working under vista
Dec 23 18:33:04 <Vajb> speaking of "forcing users to switch"
Dec 23 18:33:15 <KotCzarny> i've had w7 systems stuck on 'checking for updates' no matter what i've tried
Dec 23 18:33:58 <Vajb> there used to be ms fixit tool which worked with vista, but that is no more. Instead they offer .diagcap and that works in w7 and up
Dec 23 18:34:29 <KotCzarny> yup, there is a tool for w7 too. didnt work often
Dec 23 18:34:51 <sicelo-> i feel like reinstalling my X40 - i've been using Debian Testing with KDE. Not happy with KDE (akregator crashes too often). Not sure if I should go back to Gnome or go with lxde/xfce :-/
Dec 23 18:35:03 <Vajb> i like cmd apt-get i can see what is happening that good looking knight rider rip off doesn't tell much
Dec 23 18:35:21 <KotCzarny> sicelo: use lxde? or even fluxbox? or mate?
Dec 23 18:35:33 <KotCzarny> no need to reinstall, just switch DE
Dec 23 18:35:49 <sicelo-> lxde vs. xfce .. whis is usually bette?
Dec 23 18:35:52 <KotCzarny> you definitely want something light
Dec 23 18:35:56 <KotCzarny> both are fine
Dec 23 18:36:12 <KotCzarny> so up to your liking
Dec 23 18:36:13 <sicelo-> reinstall because i want to see if i 'solve' the hibernation issue
Dec 23 18:36:45 <sicelo-> tbh both Gnome and KDE have been fine performance-wise on the X40 :)
Dec 23 18:36:58 <Vajb> i think i've used both. Crunchbang has xfce i think
Dec 23 18:36:58 <sicelo-> will look at fluxbox a bit more
Dec 23 18:37:17 <Vajb> both r too bloated for my system
Dec 23 18:38:06 <Vajb> i like the feature that i can get to menu from anywhere on background
Dec 23 18:38:12 <sicelo-> specs?
Dec 23 18:38:28 <Vajb> 1,3ghz amd tb
Dec 23 18:38:47 <Vajb> around 700mb of ram
Dec 23 18:39:23 <Vajb> some geforce 5x series agb display card
Dec 23 18:39:45 <KotCzarny> try fluxbox
Dec 23 18:40:36 <sicelo-> mine is 1.4GHz, 1GB RAM, on-board graphics. i find gnome/kde perfectly useable. anyway, i am happy with N900 performance, so ... :)
Dec 23 18:40:42 <Vajb> it is kind of sad that cpu power nowadays is "limitless"
Dec 23 18:40:54 <KotCzarny> its not ;)
Dec 23 18:40:54 <Vajb> no one bothers to optimize
Dec 23 18:41:00 <Vajb> especially web pages
Dec 23 18:41:26 <Vajb> my puter used to be fine in flash6 time
Dec 23 18:41:39 <Vajb> i could browse anything and watch the videos
Dec 23 18:41:40 <KotCzarny> i had 1ghz tb too
Dec 23 18:41:53 <KotCzarny> still have that cpu in the closet probably
Dec 23 18:43:12 <Vajb> take it in use
Dec 23 18:43:19 <Vajb> play with puppy linux
Dec 23 18:43:27 <KotCzarny> i can send it to you if you want
Dec 23 18:43:29 <KotCzarny> :)
Dec 23 18:43:57 <Vajb> i got laptop which had busted hdd so i installed puppy into usb memory and it was lightning fast
Dec 23 18:44:02 <KotCzarny> for me it's only thinkpads + my gaming rig
Dec 23 18:44:22 <KotCzarny> and remember, i have and use and love my x40
Dec 23 18:44:35 <KotCzarny> pentium-m single core @1.2ghz, 1.5gb ram
Dec 23 18:44:43 <Vajb> yet another lenovo?
Dec 23 18:44:44 <KotCzarny> only thing that makes it fly is hdd
Dec 23 18:44:46 <KotCzarny> ssd i mean
Dec 23 18:44:50 <sicelo-> same here
Dec 23 18:44:50 <KotCzarny> nope. original ibm :P
Dec 23 18:45:00 <Vajb> oh i see
Dec 23 18:45:23 <sunshavi> KotCzarny: You have more power than my compaq evo n600c
Dec 23 18:45:27 <sicelo-> i would love to up the RAM to 1.5GB as well. currently have 1GB
Dec 23 18:45:28 <Vajb> pentium m? Mobile? That low end processor serie?
Dec 23 18:45:59 <sicelo-> Vajb: http://www.thinkwiki.org/wiki/Category:X40
Dec 23 18:46:06 <Vajb> i'd love to have some 512mb sdram
Dec 23 18:46:21 <Vajb> was there ever 1024mb?
Dec 23 18:46:28 <KotCzarny> yup
Dec 23 18:46:52 <KotCzarny> base(soldered) 512megs, and 1gb module
Dec 23 18:46:55 <Vajb> oh so basically i could have 3gigs of memory 0.0
Dec 23 18:47:10 <sicelo-> i'm used to debian now (blame N900) ... what other distro could i try (not Ubuntu/Mint) ... 
Dec 23 18:47:16 <Vajb> mb has 3 slots
Dec 23 18:47:28 <KotCzarny> sicelo: devuan?
Dec 23 18:47:44 <KotCzarny> if you like cmdline/scripts and doing most things by hand slackware
Dec 23 18:47:48 <Vajb> sicelo-: try crunchbang follower
Dec 23 18:47:54 <Vajb> can't remember the name
Dec 23 18:47:59 <KotCzarny> if you like things compiled for your setup, gentoo
Dec 23 18:48:22 <sicelo-> compiling on X40 .. sounds like fun :)
Dec 23 18:48:34 <KotCzarny> ever heard of distcc? ;)
Dec 23 18:48:59 <sicelo-> never looked at it in detail
Dec 23 18:49:15 <KotCzarny> essentially you need same gcc/g++ on other machine and network
Dec 23 18:49:49 <KotCzarny> and its like your compiling capabilities multiplied. but in case of x40 (single core) preprocessing takes most of the time
Dec 23 18:51:47 <KotCzarny> hmm, i might've lied about 1gb sdram (forgot x40 uses ddr1)
Dec 23 18:53:23 <Vajb> well actually i meant sdram sticks to my desktop ;)
Dec 23 18:53:35 <KotCzarny> yeah, that's what i meant
Dec 23 18:53:48 <KotCzarny> thought x40 uses sdram (and i have 1gb stick in it)
Dec 23 18:53:59 <Vajb> ah i see
Dec 23 18:54:25 <Vajb> i thin i have 256+256+128
Dec 23 18:54:35 <KotCzarny> check if you can get x40/x60/x61 cheap enough
Dec 23 18:54:36 <Vajb> think too
Dec 23 18:56:44 <sicelo-> verdict about Arch?
Dec 23 18:57:03 <sunshavi> sicelo: i am an arch user
Dec 23 18:57:32 <Vajb> tried once long time ago didn't instantly fell in love
Dec 23 18:57:42 <sunshavi> nice for me, but when ready i am going to move to bsd for avoiding the systemd issue
Dec 23 18:57:59 <sunshavi> I have more than 10 years using it.
Dec 23 18:58:22 <sunshavi> But distro is not important when using emacs. Distro is just a boot loader
Dec 23 18:59:12 <Vajb> care to buy vowel? BSOD
Dec 23 18:59:25 <DocScrutinizer05> (re AHJ vs OMTP) http://allaboutwindowsphone.com/flow/item/17561_Jays_AB_headset_for_Windows_Ph.php  and again >>F U Apple and whoever was involved in chosing to have the most interference sensitive signal (mic) on **SLEEVE**!!!<<
Dec 23 19:00:33 <sicelo-> i have also thought about bsd .. but maybe when i get to reinstall my box (which i've been wanting to do for 12+ months now)
Dec 23 19:00:45 * DocScrutinizer05 suggests swapping sleeve and center pin for RCA/Cinch jacks too, just "necause we can"
Dec 23 19:01:21 <sicelo-> wonder if i shouldn't try slackware instead for now :-/
Dec 23 19:01:33 <sunshavi> nice thing about arch is pkgs are always up to date. so probably my way is going to be pacbsd
Dec 23 19:09:31 <KotCzarny> sicelo, you dont have to reinstall, with linux you can have multiple systems on one drive
Dec 23 19:12:16 <sicelo-> i don't have large HDD though
Dec 23 19:13:15 <KotCzarny> 8gb per os should be fine these days, unless specifically finetuned
Dec 23 20:12:42 <Oksanaa> Anybody got mscim to work? I installed mscimswitcher, mscim-hangul, mscim-tables-ja, and all I got is "mscim=no virtual keyboard"
Dec 23 21:00:49 <sicelo-> perhaps OT: a day or two ago i mentioned that i had problems with USB on the X40 .. incidentally, USB devices are nicely detected if I plug it in the cardbus adapter, then suspend the system. 
Dec 23 21:00:53 <sicelo-> weird
Dec 23 23:03:12 <Pali> DocScrutinizer05: https://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power;a=commit;h=0533144967fcf0cc4e485cf40e586140e7a1d960
Dec 23 23:03:28 <Pali> we already have this patch in kp53
Dec 23 23:03:50 <Pali> which via that input device report *immediately* state of eci0 gpio when changed
Dec 23 23:03:54 <Pali> https://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power;a=blob;f=kernel-power-2.6.28/debian/patches/nokia-av_key.patch
Dec 23 23:04:48 <Pali> it is called at begining of that irq handler for eci0
Dec 23 23:07:06 <Pali> so via poll() on that /dev/input/ device (created after plugging headset; disappear after unplugging) you can wait for events
Dec 23 23:10:30 <Pali> and /dev/input device events contains timestamp!
Dec 23 23:10:54 <Pali> struct input_event { struct timeval time; __u16 type; __u16 code; __s32 value; }
Dec 23 23:11:00 <Pali> this is structure which send
Dec 23 23:12:40 <Pali> type is EV_KEY (0x01); code is KEY_PROG1 (148); value is boolean negation of eci0 gpio state
Dec 23 23:13:04 <Pali> if input subsystem is fast enough we do not need any kernel patching!
Dec 23 23:13:53 <DocScrutinizer05> yes! great :-))
Dec 23 23:15:08 <DocScrutinizer05> actually only needs to be "fast enough" to get timestamp and handle forward it before next IRQ after 80us comes in
Dec 23 23:16:41 <Pali> do you need to process eci0 realtime, or is "buffered" enough with correct timestamp?
Dec 23 23:17:04 <Pali> e.g. if you get ten events at once, but with timestamp
Dec 23 23:18:14 <DocScrutinizer05> the process which soes "poll() on that /dev/input/ device" probbaly needs realtime scheduling prio, and stay active (not allow scheduler to do task switching) until no more inbound events from poll for a 20ms
Dec 23 23:18:56 <DocScrutinizer05> even 32 or 40 events with timestamp are fine when just buffered
Dec 23 23:19:53 <Pali> this needs experiment if input layer is enough or not
Dec 23 23:19:54 <DocScrutinizer05> it seems no reply sent by headset is longer a burst than 2 bytes
Dec 23 23:20:59 <DocScrutinizer05> after the 16 (18 incl startbits) bits are sent, the userland process can analyue the buffered events and has "all the time of this world" to do so
Dec 23 23:21:21 <DocScrutinizer05> 18 bits = 36 events
Dec 23 23:22:22 <DocScrutinizer05> analyze*
Dec 23 23:23:17 <DocScrutinizer05> 36 events -> 2 bytes ==>/dev/eci or dbus-signal or whatever
Dec 23 23:24:42 <DocScrutinizer05> communication layer then sends a respomse, if needed. Or next command if needed. Or simply makes sure the event queue is empty and everything ready to receive next event
Dec 23 23:25:21 <DocScrutinizer05> time until respinse or next command isn't critical aiui, it may take several dizen milliseconds
Dec 23 23:25:38 <DocScrutinizer05> God!
Dec 23 23:25:48 <DocScrutinizer05> time until response or next command isn't critical aiui, it may take several dozen milliseconds
Dec 23 23:31:32 <DocScrutinizer05> afaik (so far), Device sends 4ms low pulse to start session, on plug-in. Headset responds with a single startbit. D sends IDENTIFY command (0xf0a5 or whatever). H responds with some 2 byte(?) answer. D prolly sends read-memory commands like read(1) read(2) aso. H resp content of byte 1, byte 2 etc of config storage.  eventually session established and HS initialized. Now when user presses a key on HS, it sends 2byte info and Device sends 
Dec 23 23:31:33 <DocScrutinizer05> ACK a few ms later
Dec 23 23:33:26 <Pali> and must device start session immediately after plug-in? or can be it e.g. 10sec after plug-in?
Dec 23 23:33:52 <Pali> because it takes some time after udev create /dev/input device after plug-in
Dec 23 23:37:31 <DocScrutinizer05> I think the session gets started by 4ms of low pulse
Dec 23 23:37:35 <DocScrutinizer05> at any time
Dec 23 23:37:57 <Pali> and session is started by device? or by headset?
Dec 23 23:38:03 <DocScrutinizer05> by device
Dec 23 23:38:25 <Pali> ok, then slow udev and creating input device should not be a problem
Dec 23 23:38:51 <DocScrutinizer05> http://neo900.org/stuff/joerg/ECI/init/
Dec 23 23:39:28 <DocScrutinizer05> http://neo900.org/stuff/joerg/ECI/init/ECI_init01_ph4ms_low_hsA2pulses.jpg
Dec 23 23:39:48 <DocScrutinizer05> og, HS answers with TWO startbit
Dec 23 23:39:54 <DocScrutinizer05> oh*
Dec 23 23:41:07 <DocScrutinizer05> note how the HS pulses have a lower low voltage (hard to see but it's there)
Dec 23 23:41:42 <DocScrutinizer05> and HS pulses also have that tiny bright line at beginning of falling edge
Dec 23 23:43:06 <DocScrutinizer05> in http://neo900.org/stuff/joerg/ECI/init/ECI_init01_ph4ms_low_hsA2pulses.jpg you see 4ms wide start pulse by Device, then 2 startbit pulses by HS, then on right side you see the Device sending IDENTIFY command
Dec 23 23:43:20 <DocScrutinizer05> after 4.x ms
Dec 23 23:43:40 <DocScrutinizer05> I'm sure those 4.x ms are not critical
Dec 23 23:44:40 <DocScrutinizer05> http://neo900.org/stuff/joerg/ECI/init/ECI_init02_phCMD_identify.jpg is the IDENTIFY command shifted into screen from right
Dec 23 23:46:15 <DocScrutinizer05> HS replies by http://neo900.org/stuff/joerg/ECI/init/ECI_init03_hsANSWER_ident.jpg
Dec 23 23:46:25 <Pali> anyway, how is that defaul n900 headset with button working?
Dec 23 23:46:33 <Pali> it is ECI? or different protocol?
Dec 23 23:46:40 <DocScrutinizer05> and sorry I was wrong, those seem to be 4 byte
Dec 23 23:47:31 <DocScrutinizer05> default has no damn clue about boolean logic, it siply shirts MICBIAs to GND as long as you press the button
Dec 23 23:47:54 <DocScrutinizer05> simply shorts*
Dec 23 23:48:20 <DocScrutinizer05> so basically it sends a veeeeeery long "ECI oulse"
Dec 23 23:48:35 <DocScrutinizer05> pulse. sorry can't type anymore
Dec 23 23:51:15 <DocScrutinizer05> re high level protocol, I guess you can find all the gory details in the existing sourcecode
Dec 23 23:52:12 <DocScrutinizer05> https://lwn.net/Articles/420775/ etc
Dec 23 23:55:29 <DocScrutinizer05> as I already mentioned, my code reading of that stuff resulted in thinking that it uses whatever MCU to do the bytes -> raw pulses and back to bytes 
Dec 23 23:56:49 <DocScrutinizer05> iirc they even support TWO different MCU but have no info for either of them. So we need to emulate what the MCU does: convert byte commands to pulse bursts and bitbbang those out. And receive inbound bursts and convert them to bytes
Dec 24 00:00:12 <DocScrutinizer05> what a MCU can do, we do hands down on OMAP, without sweating our shirt ;-)
Dec 24 00:06:51 <DocScrutinizer05> I think they send the command bytes to MCU via I2C (sorry it's at least a year since I read that source):  http://mailman.alsa-project.org/pipermail/alsa-devel/2011-February/036377.html
Dec 24 00:07:23 <DocScrutinizer05> we would send them to a bitbanging kernel driver instead
Dec 24 00:08:11 <DocScrutinizer05> and instead of reading inbound bytes from I2C we would analyze the event queue to generate those data bytes
Dec 24 00:11:16 <DocScrutinizer05> or maybe s/ bitbanging kernel driver / a RT-prio userland program sending precisely timed toggle instructions for one burst to the ALSA_whatever interface to TVOUT_EN /
**** ENDING LOGGING AT Sat Dec 24 03:00:00 2016