IRC log for #maemo on 20161223

00:06.06*** join/#maemo RzR (~RzR@82.236.136.171)
00:10.39*** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net)
00:32.23*** join/#maemo florian (~fuchs@Maemo/community/contributor/florian)
00:35.59*** join/#maemo peterbjornx (~user@catena-194-171-106-2.leidenuniv.nl)
01:04.21*** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com)
01:04.25*** join/#maemo platicus (~matrixirc@fanzine.igalia.com)
01:04.59*** join/#maemo peterbjornx (~user@50709CF6.static.ziggozakelijk.nl)
01:06.36*** join/#maemo platicus (~matrixirc@fanzine.igalia.com)
01:06.48*** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com)
01:13.33*** join/#maemo Kabouik_ (~kabouik@37.160.43.86)
01:14.37*** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3)
01:15.30*** join/#maemo platicus (~matrixirc@fanzine.igalia.com)
01:15.37*** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com)
01:19.18*** part/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net)
01:20.00_maniac_rip my n900, left as temporary pawn for taxi driver who just sprinted off without waiting for money.
01:20.24_maniac_I guess he'll enjoy my gentoo chroot there.
01:20.40*** part/#maemo _maniac_ (~~~@unaffiliated/maniac/x-0943658)
01:20.50*** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net)
02:02.13*** join/#maemo RzR (~RzR@unaffiliated/rzr)
02:43.29*** join/#maemo robink (~quassel@unaffilated/robink)
02:47.38*** join/#maemo e (e@freenode/staff/spy.edk)
03:29.50*** join/#maemo Kilroo (~Kilroo@98.27.26.236)
03:33.59*** join/#maemo florian__ (~fuchs@Maemo/community/contributor/florian)
04:01.51*** join/#maemo lxp1 (~lxp@unaffiliated/lxp)
05:34.27*** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg)
06:40.00*** join/#maemo CatButts (~c@188.173.53.45)
07:18.36*** join/#maemo TheKit (~nekit@178-45-12-191.saransk.ru)
07:47.53*** join/#maemo Pali_ (~pali@Maemo/community/contributor/Pali)
07:55.13*** join/#maemo geaaru (~geaaru@host229-180-dynamic.48-82-r.retail.telecomitalia.it)
07:57.47sixwheeledbeastMaybe would have been better to pawn your leg, at least you have another one...
07:58.00bencoh:/
07:58.13KotCzarnyi think he left already
07:58.44KotCzarnybut friggin taxi driver stealing n900? the hell with the world we live in
07:59.11xessomeone was a bit drunken...or both of them
08:09.56*** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439)
08:27.24*** join/#maemo heroux (sandroco@gateway/shell/insomnia247/x-tycyilobxilajkfy)
08:34.43*** join/#maemo ShadowJK (~jk@212.7.198.194)
09:21.03*** join/#maemo shentey (~shentey@x4e341105.dyn.telefonica.de)
09:22.12DocScrutinizer05http://neo900.org/stuff/joerg/ECI/all_buttons/
09:26.30*** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439)
09:27.31DocScrutinizer05for N900 bitbang outbound data with SoC TVOUT_EN while TVOUT set to GPIO-OUT:GND/low
09:31.42DocScrutinizer05to read inbound, use ECI_AD and/or comparator N4008:ECI1:GPMC_nWP-H1 and/or N4007:ECI0:GPMC_nBE1-H3
09:32.45DocScrutinizer05particularly the latter seems very suited
09:32.54*** join/#maemo krnlyng (~liar@178.114.13.63.wireless.dyn.drei.com)
09:34.13DocScrutinizer05prolly already also used to detect holdbutton-press
09:34.34DocScrutinizer05ECI is basically just holdbutton fast morse ;-)
09:37.02DocScrutinizer05such software solution will be 100% compatible to Neo900 too
09:40.18DocScrutinizer05for 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
09:40.34*** part/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net)
09:41.04DocScrutinizer05for TX a realtime scheduled userland task might do
09:42.58DocScrutinizer05the 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
09:44.05DocScrutinizer05and even when a higher prio system interrupt will eventually mess up a burst, nothing too bad will happen
09:44.39DocScrutinizer05just make sure to disable your own RX IRQs during TX ;-)
09:45.24DocScrutinizer05well, for TWOUT_EN they won't even fire on hw level, so that's no issue
09:45.32DocScrutinizer05TV*
09:46.19DocScrutinizer05bota bene: without proper initialization a ECI headset will "act dead"
09:46.46DocScrutinizer05nota, even
09:47.10DocScrutinizer05atk: ^^^ how about that? ;-)
09:47.50DocScrutinizer05Pali: you also might be mildly interested
09:48.38DocScrutinizer05Pali: except for the "PHY layer" the solution is pretty platform agnostic
09:50.15DocScrutinizer05TV_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)
09:50.51DocScrutinizer05worst case you can emulate the latter via ALSA record ;-)
09:56.56*** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net)
09:56.59*** join/#maemo louis__ (~louisdk@static-5-103-130-65.seas-nve.net)
10:08.49DocScrutinizer05s/ TV_OUT / TVOUT_EN / 2 above
10:12.23DocScrutinizer05hint: TVOUT_EN = GPIO40
10:27.04DocScrutinizer05http://neo900.org/stuff/joerg/ECI/scopeshots/ECI_NOT__N900_plugin_for_reference.jpg
10:54.27atkDocScrutinizer05: https://lwn.net/Articles/420775/
10:54.54*** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439)
10:55.38DocScrutinizer05well, 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
10:55.39atkDocScrutinizer05: if anything, that can be used as a base, I'll try to work out why it was never accepted
10:55.59atkI see
10:58.22DocScrutinizer05so 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)
10:59.38atkIt's weird, when I google "ECI" or "Enhancement Control Interface" I get nothing relevantz
11:00.17atks/z$//
11:00.26DocScrutinizer05well, except this is a screenshot of a HS reply, so you rather see a ECIread() == 0b00100000; ECIread() == 0b00000000;
11:00.51atkI see
11:01.03DocScrutinizer05yeah, there is *very* little publicly available docs anout ECI
11:01.33atkSo these inline controls in earphones actually have logic in them?
11:01.45DocScrutinizer05yes
11:02.45atkand it's a two way protocol? This seems like a lot of work just to reuse legacy 3.5mm jacks for data transfer :P
11:02.56DocScrutinizer05yes, single wire bidir serial
11:04.01DocScrutinizer05well, they use the same for e.g SIM data, for battery embedded gas gauges (bq27000, HDQ protocol) and whatnot else
11:04.31atkSo 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?
11:05.01DocScrutinizer05actually SIM SWP is even way more complex since it uses two independent channels on one wire: master mudulates volatge while concurrently slave modulates current
11:05.29DocScrutinizer05don't you have a N900?
11:06.02DocScrutinizer05a N900 will work excellent for this
11:06.16DocScrutinizer05while on BeagleBoard the hardware is missing
11:06.44atkI see
11:06.54atkso N900 does this in software too?
11:06.58DocScrutinizer05~schematics
11:06.58infoboti heard schematics is http://wiki.maemo.org/N900_Hardware_Schematic
11:07.15DocScrutinizer05N900 doesn't do this so far, that's the point
11:07.17DocScrutinizer05:-)
11:07.30DocScrutinizer05it *could* do it with the right software
11:08.05atkAh, cool
11:08.38DocScrutinizer05my tests are done with a N97-mini and a genuine (inknown type) Nokia multibutton headset
11:11.55atkMy 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.
11:12.05DocScrutinizer05~literal schematics
11:12.05infobot"schematics" is "http://wiki.maemo.org/N900_Hardware_Schematic"
11:12.17DocScrutinizer05~schematics is also http://www.google.de/search?q=nokia+n900+rx-51+schematics.pdf&oq=Nokia_N900_RX-51_schematics
11:12.17infobotokay, DocScrutinizer05
11:13.29DocScrutinizer05http://wstaw.org/m/2016/12/23/plasma-desktopN17764.png
11:15.02DocScrutinizer05http://maemo.cloud-7.de/share-service/20161222_002.jpg my test setup
11:15.52DocScrutinizer05(without scope probe attached yet, goes to the yellow clip)
11:17.00DocScrutinizer05note 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
11:19.16DocScrutinizer05http://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
11:21.13DocScrutinizer05http://neo900.org/stuff/joerg/ECI/init/ECI_init00.png http://neo900.org/stuff/joerg/ECI/init/ECI_init01_ph4ms_low_hsA2pulses.jpg
11:21.55DocScrutinizer05note how in the latter the two short pulses after the 4ms intitial one are from HS, they are lower voltage
11:23.15DocScrutinizer05and have that tiny "mark" on beginning of falling edge: http://wstaw.org/m/2016/12/23/plasma-desktopc17764.png
11:23.52DocScrutinizer05which in fact is the initial slight voltage drop to be seen in http://neo900.org/stuff/joerg/ECI/scopeshots/ECIpulseHS.jpg
11:28.11DocScrutinizer05your 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)
11:29.24DocScrutinizer05the sigle bit seems to be encoded as either 1 low 4 high (unit 100us?) or 4 low 1 high
11:30.37DocScrutinizer05err sorry, rather it's 4h1l  or 1h4l
11:30.59DocScrutinizer05startbit is 4h1l it seems
11:31.27DocScrutinizer05you don't see the leading 4h since the line is h all the time when inactive
11:33.08DocScrutinizer05when 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
11:42.00*** join/#maemo LauRoman (~LauRoman@5-14-158-237.residential.rdsnet.ro)
11:42.26DocScrutinizer05even 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
11:43.55DocScrutinizer05I'd expect you find a "IDENTIFY" (owtte) command in the existing ECI sources, of a value like 0x0f00 or 0xf0ff
11:46.43DocScrutinizer05oops sorry, I slipped
11:48.01DocScrutinizer05startbit(1) [data]00001111   >>WHATSTHIS???(1timeunit-h,1timeunit-l)=startbit_with shirt-hightime?(1)<<  [data]01011010  <finish>
11:50.11DocScrutinizer05so a value like 0x0f5a or 0xf0a5
11:53.20DocScrutinizer05let's define startbit=100us-high + 100us-low; bit1= 400us-high + 100us-low; bit0= 100us-high + 400us-low  --- just as a working hypothesis
11:54.19DocScrutinizer05and data frame format = 1 startbit, 8 data bits, no stop bit
11:56.39DocScrutinizer05hmm, make that 80us and 320us
11:57.04DocScrutinizer05doesn't matter I guess. And easy to tune in source later on
12:02.34DocScrutinizer05anyway, 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)
12:03.44DocScrutinizer05IroN900:~# find /sys -iname '*eci*'
12:03.46DocScrutinizer05/sys/devices/platform/nokia-av/eci0
12:03.47DocScrutinizer05/sys/devices/platform/nokia-av/eci1
12:03.49DocScrutinizer05/sys/devices/platform/soc-audio/eci_mode
12:08.28DocScrutinizer05eci0 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 ;-)
12:08.51DocScrutinizer05so what you want to read is /sys/devices/platform/nokia-av/eci1
12:09.08DocScrutinizer05or rather monitor with your IRQ handler
12:10.01DocScrutinizer05of course for a mere POC you could also poll with a period of 80us
12:11.16DocScrutinizer05hmm, prolly rather 50us
12:18.07DocScrutinizer05IroN900:/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)
12:18.08DocScrutinizer05real    0m0.593s
12:20.06DocScrutinizer05so this thing already polls @ 70us
12:20.50DocScrutinizer05should be able to read out a HS response raw data (to a real file instead of /dev/null)
12:22.26DocScrutinizer05I'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
12:27.41*** join/#maemo auenf (David@DC-50-235.bpb.bigpond.com)
12:30.34*** join/#maemo Konsieur (~kabouik@37.166.150.28)
12:30.38DocScrutinizer05IroN900:/sys/devices/platform/nokia-av# time (for (( i=0; i<1000; i++ )); do read r <eci0; echo -n "$r:"; done >/dev/null)
12:30.40DocScrutinizer05real    0m0.546s
12:53.16Palihere 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
12:56.33Paliand here is rx51_set_eci_mode function: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/sound/soc/omap/rx51.c#L175
12:57.28Paliso it change RX51_ECI_SWITCH_1_GPIO and RX51_ECI_SWITCH_2_GPIO gpios
12:57.36Pali#define RX51_ECI_SWITCH_1_GPIO178
12:57.41Pali#define RX51_ECI_SWITCH_2_GPIO182
13:02.29DocScrutinizer05looks 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
13:04.21DocScrutinizer05puzzling results are: ECI0 always "0" while detect goes "4" -> "2" when pressing the hold button
13:04.47DocScrutinizer05and even madc is always at around 4 or 5
13:05.18DocScrutinizer05I already thought my headset was defect until I noticed the detect value change
13:05.51Palino, nobody in Maemo is doing anything with eci_mode sysyfs
13:05.59Paliat least not in stock PR1.3
13:06.22DocScrutinizer05then those nodes provide not at all what their names suggest
13:06.29Paligrepped rootfs of PR1.3 /mnt/n900/{bin,lib,sbin,usr/lib,usr/bin,usr/sbin}
13:07.29DocScrutinizer05madc=4 means what? a 100mV on micbias?
13:08.16PaliADCIN4 - Battery size indicator
13:08.25DocScrutinizer05and even if that was true, how the heck does "detect" notice holdbutton press while madc doesn't change value?
13:08.57DocScrutinizer05not ADCIN4
13:09.23DocScrutinizer05/sys/devices/platform/nokia-av/madc
13:09.25Palilook: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L280
13:09.42DocScrutinizer05value = 4
13:10.44Palithat madc sysfs returns value fomr ADCIN2
13:10.49PaliADCIN2 - ECI AD
13:11.06Paliand that value = 4 is RAW value
13:11.28PalimV = RAW * 147 / 60
13:13.08DocScrutinizer05~4*147/50
13:13.08infobot11.76
13:13.15Paliso it is 9.8mV
13:13.22Pali~4*147/60
13:13.22infobot9.8
13:13.23DocScrutinizer05doesn't make sense
13:14.05DocScrutinizer05madc is always 4 or 5 no matter if I push holdbutton or not
13:15.33DocScrutinizer05so whatever `cat /sys/devices/platform/nokia-av/madc` shows, it's quite evidently not the voltage on mic line of AV jack
13:16.19*** join/#maemo zGrr (~Grr@188.146.155.100.nat.umts.dynamic.t-mobile.pl)
13:17.04Palido you have mic bias enabled?
13:17.24DocScrutinizer05use 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
13:17.29Palibecause alsaped maemo daemon is automatically disabling it when headset is plugged
13:17.37Paliok, going to test
13:17.51DocScrutinizer05Pali: it detects holdbutton press, and holdbutton shorts micbias to GND
13:18.35DocScrutinizer05so yes, obviously (and according to http://neo900.org/stuff/joerg/ECI/scopeshots/ECI_NOT__N900_plugin_for_reference.jpg) my MICBIAS is enabled
13:19.31DocScrutinizer05http://paste.opensuse.org/40688624
13:20.57DocScrutinizer05stock kernel here!
13:21.10DocScrutinizer05with CSSU
13:23.12DocScrutinizer05the 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
13:24.10DocScrutinizer05madc not changing at all while value of detect changes with holdbutton status indicated madc is bogus
13:25.37DocScrutinizer05I'd also expect eci0 to be 1 as long as hold button not pressed. It's always 0
13:26.09DocScrutinizer05conclusion: kernel driver fubar
13:26.49DocScrutinizer05eci is 1 as long as no hs plugged at all
13:27.16DocScrutinizer05sth is fuxored there
13:31.15Palimadc here is about 68
13:31.15DocScrutinizer05ohmmy! I guess I know what's happening. I suspect `cat detect` enables micbias, checks button status, and disables micbias again
13:31.28Paliand sometimes when I push button then madc is 135
13:31.31Palibut just sometimes
13:32.14DocScrutinizer05I wondered why the cmdline takes that looooong
13:32.17Paliand if I start pressing button to quick madc goes above 210
13:32.26DocScrutinizer05o.O
13:32.38DocScrutinizer05that's not ok for sure
13:32.56KotCzarnysome counter?
13:33.02Palisee what is cat detect doing: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L280
13:33.12Paliit changes those GPIOs
13:33.12DocScrutinizer05with headset unplugged, my madc is at 1024 around
13:33.20KotCzarnycheck if it changes with the rate you are pressing
13:34.40DocScrutinizer05Pali: so quite possibly my micbias is NOT enabled all the time
13:35.05DocScrutinizer05Pali: and it seems yours isn't as stable as it's supposed to be, as well
13:35.37DocScrutinizer05the dependency on push speed is from R-C charging of micbias voltage buffer cap
13:36.15Palibah!! cat detect disable mic bias
13:36.18Palisee alsamixer -c 0
13:36.19DocScrutinizer05something's totally messed up in there
13:36.58DocScrutinizer05yes, see what I said above: obviously cat detect enables micbias to run the tests and then disables it again
13:37.15Palinow when mic bias is always enabled, then madc is about 317
13:37.32Paliand when I press button it is about 68
13:37.40DocScrutinizer05now that makes sense :-)
13:38.05DocScrutinizer05how would I enable micbias?
13:38.12Palialsamixer -c 0
13:38.15DocScrutinizer05ta
13:38.17Paliand find "jack bias"
13:38.25Paliand use 'm' key
13:38.34Palito switch between on/off
13:39.19KotCzarnyoscp uses micbias to detect button presses on nokia headsets
13:39.39KotCzarnys/micbias/jack bias/
13:39.43DocScrutinizer05amixer -c 0 scontrols|grep -i bias
13:40.31Palilooks like nobody in maemo is accessing /sys/devices/platform/nokia-av/detect
13:40.57Pali(only /usr/lib/testserver/modules/handlers/selftests.so.0)
13:41.15Pali(but whole testserver is irrelevant there as it is not running in normal Maemo)
13:41.54Pali~65*147/60
13:41.54infobot159.25
13:42.06Pali~317*147/60
13:42.06infobot776.65
13:42.24Palihm... so 160mV and 780mV?
13:44.23DocScrutinizer05amixer -c 0 cset name='Jack Bias Switch' 1
13:45.18Paliyes
13:45.33DocScrutinizer05http://paste.opensuse.org/38383984
13:45.55Palianyway, CSSU in some version automatically enable jack bias after inserting headset with mic
13:47.57DocScrutinizer05DAMMIT! phonecall, no audio. I guess it tried to use a headset thats not there
13:48.06DocScrutinizer05:-/
13:48.54DocScrutinizer05I should start to use a test device for such experiments again
14:15.13DocScrutinizer05Pali: do you know what autodetect sysnode does?
14:15.32DocScrutinizer05in /sys/devices/platform/nokia-av/autodetect
14:17.25Paliyes, it just control variable autodetect
14:17.33Paliand that is used only here: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L456
14:17.47Paliwhen set to zero then that headph_handler is noop
14:19.23*** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net)
14:19.38DocScrutinizer05HAH! after boot, with hs plugged in:  eci0:1  eci1:1  detect:3  type:2  /sys/devices/platform/soc-audio/eci_mode:1  madc:1023
14:20.55PaliI updated https://wiki.maemo.org/Porting/Kernel#Porting
14:21.18Palinow cssu can boot without /proc/bootreason and /dev/twl4030-adc
14:22.32DocScrutinizer05plug-cycled, NOW we're talking! :) http://paste.opensuse.org/83643851
14:23.37DocScrutinizer05Pali: (cssu) excellent, that stuff is pretty much pointless, particularly the twl4030-adc for BSI test battery
14:24.39Paliwe need to also get rid off /proc/component_version and /sys/class/gpio-swich
14:24.44DocScrutinizer05I *guess* bootreason makes some sense for deciding if to re-use an existing PIN or ask for it again
14:25.21PaliI mean, maemo cssu can boot without those files
14:25.34Paliif files are provided they are used
14:25.53DocScrutinizer05meh /proc/component_version
14:26.05DocScrutinizer05what the heck?!
14:26.05Paliif not, then fallback mechanism is used (e.g. /proc/cpuinfo or /proc/atags) or hardcoded strings, eg. bootreason is pwr_key
14:26.22DocScrutinizer05compiled in to kernel (DT?)
14:26.26Palicomponent version is key/value file
14:26.31Paliwith data from NOLO
14:26.35Palipassed via ATAGs
14:26.36DocScrutinizer05ohmy
14:27.03DocScrutinizer05ATAGs my headache
14:27.11Paliand nolo pass just: board name, hw revision, nolo version and boot mode
14:27.31Paliand boot mode is either "normal" or "update"
14:27.48Paliand some rcS script check for "update" and enter into different runlevel
14:27.49DocScrutinizer05I wonder how hard it could get to completely replace NOLO by uboot
14:28.01Paliwhen just softup via usb is running
14:28.10Palialready tried to replace NOLO with uboot
14:28.15Paliand I failed
14:28.22DocScrutinizer05yeah I know
14:28.27DocScrutinizer05wonder why, though
14:28.31Pali1. problem is size 100kB
14:28.37DocScrutinizer05ugh
14:28.37Paliuboot is big :-(
14:29.02Pali2. problem uboot has broken onenand support (or had in ~~ 2012)
14:29.16DocScrutinizer05doubleplusugh
14:29.17Pali3. problem uboot has broken omap3 usb
14:29.34DocScrutinizer05ohmy
14:30.13Pali4. problem no idea which hw initialization is needed to implement
14:30.30DocScrutinizer05sounds nasty
14:30.47Paliwe have no idea what it is doing... probably some SSI/modem init is needed too...
14:31.04DocScrutinizer05isn't there a working uboot for pandora and beagleboard?
14:31.27DocScrutinizer05oooh modem init
14:31.28Paliand at that time in uboot was no support for spi... so no display init code
14:31.41DocScrutinizer05ouch
14:31.44Palipandora and beagleboard is probably working fine with uboot
14:31.53Palibut thse do not have nokia's SSI modem
14:32.00DocScrutinizer05yeah sure
14:32.17Paliuboot is working fine on n900, just it needs to be loaded by nolo :-)
14:32.24DocScrutinizer05but... the modem should get initialized only lated, by kernel
14:32.29DocScrutinizer05later*
14:32.37KotCzarnyglue uboot to nolo
14:32.43KotCzarnyor nolo to uboot
14:32.59Palinolo can flash fw for modem...
14:33.07Paliso there is big blob in nolo for that
14:33.15DocScrutinizer05eeek
14:33.16Paliand no idea if some init is really not needed...
14:33.30PaliKotCzarny: see first problem about size
14:33.35DocScrutinizer05are you sure modem flashing done by nolo?
14:33.49Palieither by nolo or via some RPC
14:34.15DocScrutinizer05I thought it's done along softupd foo
14:34.32Palisoftupd can do that
14:34.36Palibut nolo too!
14:34.46DocScrutinizer05incredible
14:34.53Paliand via usb cable to flasher-3.5 nolo exports some strange protocol for modem flashing status
14:35.08DocScrutinizer05I see
14:35.10Paliwhich is different from other notification
14:35.24DocScrutinizer05yep, of course. It's Nokia shit
14:35.42Palievery status information to flasher-3.5 has one format, just modem flashing status has different
14:35.43DocScrutinizer05F-Bus
14:35.58Paliit is string based (for flasher-3.5)
14:36.12Palibut some f-bus is probably used in nolo and softupd
14:36.46DocScrutinizer05this? http://shodhganga.inflibnet.ac.in/bitstream/10603/64948/9/09_chapter 3.pdf
14:38.23DocScrutinizer05possibly for flashing even M-Bus, not F-Bus
14:39.13Paligoing to look at that protocol
14:39.19DocScrutinizer05http://mennucc1.debian.net/lacie_network_space/nokia-ca-42/Embedtronics - Nokia F-Bus Protocol made simple.html
14:39.24Paliand compare it with what I sniffed and implemented in 0xFFFF
14:41.10Palino, protocol is totally different
14:41.23DocScrutinizer05http://wiki.gnokii.org/index.php/MBUS_protocol
14:41.51DocScrutinizer05check Phoenix flashers
14:42.19DocScrutinizer05http://www.allmobiletools.net/2014/12/nokia-phoenix-service-software-201415.html
14:42.56DocScrutinizer05sorry for the useless link
14:43.16DocScrutinizer05https://nokiarevolution.com/how-to-flash-your-nokia-device-via-phoenix-usb-dead-flashing/
14:44.09DocScrutinizer05not much info but for sure the right protocol we're looking for
14:44.23DocScrutinizer05*all* nokia phones use that protocol
14:44.41Paliwhat softupd thing uses different protocool
14:44.56DocScrutinizer05either via serial (M-bus, F-bus, whatever) or via USB with some wrapper protocol aiui
14:45.01Palisee: https://github.com/pali/0xFFFF/blob/master/doc/mkii
14:45.52DocScrutinizer05yeah softupd is not using phoenix protocol, they use something they made up for maemo
14:46.31DocScrutinizer05I however bet they embedded the phoenix protocol into softupd for BB5-modem flashing
14:46.37Palianyway, phoenix IIRC uses same protocol for n900
14:46.59Paliand it uses that testserver
14:47.11DocScrutinizer05quite possible, yes
14:47.27DocScrutinizer05BSI crap
14:47.42DocScrutinizer05"lab battery"
14:48.41PaliI have some information that FIASCO format is some BB5 format
14:50.05DocScrutinizer05oooh
14:50.44DocScrutinizer05at least that explains CAL
14:51.15DocScrutinizer05CAL looks *very much* like invented for modem "filesystem"
14:52.04DocScrutinizer05and this is what Phoenix modifies for stuff like ALS calibration etc
14:52.27Paliit uses testserver for that
14:52.38Paliand testserver has plugin for als
14:52.40DocScrutinizer05quite possible
14:52.47Paliso this probably access CAL
14:52.57PaliIIRC nolo does not export any access to CAL over usb
14:53.13PaliI already tried to do anything...
14:53.27Palialso no "backup" support seems to be in NOLO
14:59.15DocScrutinizer05yeah, no Nokia phone has that, prolly considered a security feature
15:00.48DocScrutinizer05anyway seems ECI0 is working like supposed, when enabling micbias. So would you know how to control TVOUT_EN?
15:05.02Paliin sound/soc/omap/rx51.c is: #define RX51_TVOUT_SEL_GPIO40
15:05.11Paliit is this gpio?
15:07.49DocScrutinizer05yes
15:07.58Palithat is exported to alsa
15:08.04DocScrutinizer05ouch
15:08.08PaliRX51_JACK_TVOUT
15:08.24DocScrutinizer05much overhead to toggle itt
15:08.34Paliwhen rx51_jack_func is RX51_JACK_TVOUT then RX51_TVOUT_SEL_GPIO is set to 1
15:08.38Paliotherwise to 0
15:09.41Palibut should be possible to control it via /sys/class/gpio
15:09.44Palias any other gpio
15:09.49DocScrutinizer05I want to create 0.8ms pulses on this GPIO
15:10.25DocScrutinizer05err 0.08ms
15:10.56DocScrutinizer05I can poll eci0 with almost 2000/s
15:11.03Palibah, linux kernel refuse to export it :-(
15:11.46Pali# echo 40 > /sys/class/gpio/export
15:11.46Palibash: echo: write error: Device or resource busy
15:12.18Paliprobably because that alsa driver already has it for its own
15:12.55DocScrutinizer05yep
15:13.34DocScrutinizer05also I just realized I did a decimal error, 2000/s is factor 10 too slow for ECI still
15:16.01DocScrutinizer05Pali: you looked into the ECI stuff I pstaed a few hours ago?
15:16.06DocScrutinizer05pasted
15:16.44DocScrutinizer05Pali: http://mg.pov.lt/maemo-irclog/latest.log.html#t2016-12-23T11:22:12
15:17.07Paliyes, I have seen it
15:23.41DocScrutinizer05Pali: 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?
15:25.30Pali/sys/class/gpio/ already supports it
15:25.35Palivia poll on sysfs
15:25.38DocScrutinizer05wow
15:25.46Palibut that sound driver refuse to do it
15:26.03DocScrutinizer05wait, sorry?
15:26.18DocScrutinizer05you're not referring to eci0 now, do you?
15:26.43PaliI mean that gpio 40
15:26.51Paliwith # echo 40 > /sys/class/gpio/export
15:26.55DocScrutinizer05aka TVOUT_EN?
15:26.59Paliyes
15:27.03DocScrutinizer05:nod:
15:27.15Palibut that should work for any gpio number
15:27.43KotCzarnysome years ago i saw a project using vga card as a fm radio generator
15:27.56Pali[13:57:36] <Pali> #define RX51_ECI_SWITCH_1_GPIO                178
15:27.56Pali[13:57:41] <Pali> #define RX51_ECI_SWITCH_2_GPIO                182
15:28.07Palithose gpios are also owned by sound driver
15:29.53DocScrutinizer05so not exactly trivial to add an IRQ handler listening to that GPIO178 aka eci0, right?
15:30.17Palilooks like not
15:30.34Palimaybe some debug interface could exist...
15:30.48DocScrutinizer05though actually on hw level IRQ is sort of unentangled and orthogonal to GPIO-IN/OUT
15:31.49DocScrutinizer05a process doing i/o via GPIO doesn't need to know or care about an IRQ set up for that GPIO, and vice versa
15:32.15DocScrutinizer05particularly for input
15:43.01Palisome info is there: cat /sys/kernel/debug/gpio
16:03.07*** join/#maemo cyphase (~cyphase@unaffiliated/cyphase)
16:08.02DocScrutinizer05o.O !!!   "gpio-61  (eci0                ) in  hi irq-221 edge-both"
16:08.34DocScrutinizer05YES! URQ edge-both, exactly what we need
16:08.41DocScrutinizer05IRQ*
16:11.38DocScrutinizer05in 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
16:12.42DocScrutinizer05usually that "userland process" is called worker thread
16:12.58DocScrutinizer05and actually runs in kernel domain still
16:14.54DocScrutinizer05UGH, should be a wakeup IRQ though#
16:15.31DocScrutinizer05irq-221 edge-both wakeup
16:16.51Pali2.6.28 kernel does not support poll() syscall for gpio :-(
16:17.03Palihttps://www.kernel.org/doc/Documentation/gpio/sysfs.txt
16:17.08Palithis is upstream kernel
16:17.11Palisearch for /sys/class/gpio/gpioN/
16:17.27Palithis is probably enough for upstream kernel
16:17.34Palibut not for maemo 2.6.28
16:17.58DocScrutinizer05not 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
16:19.01*** join/#maemo cyphase (~cyphase@unaffiliated/cyphase)
16:19.09DocScrutinizer05Pali: afaik kernel IRQ handlers should be chainable
16:20.21DocScrutinizer05so 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?
16:20.45Palibut kernel gpio library does not allow it
16:21.39DocScrutinizer05damn!
16:21.54DocScrutinizer05seems it creates a /dev/input device
16:22.33DocScrutinizer05Dec 23 16:05:53 IroN900 kernel: [ 4663.989837] headphone (GPIO 177) is now connected
16:22.35DocScrutinizer05Dec 23 16:05:54 IroN900 kernel: [ 4665.067871] input: headset button as /class/input/input6
16:23.08DocScrutinizer05how 'realtime' could that get?
16:23.51DocScrutinizer05IroN900:/sys/devices/platform/nokia-av# Dec 23 16:05:48 IroN900 kernel: [ 4658.466400] headphone (GPIO 177) is now disconnected
16:23.53DocScrutinizer05Dec 23 16:05:48 IroN900 ke_recv[1548]: device_removed:2695: udi: /org/freedesktop/Hal/devices/computer_logicaldev_input_1
16:23.54DocScrutinizer05Dec 23 16:05:49 IroN900 mce[830]: Error accessing /dev/input/event4 (condition: 16). Ignoring
16:23.56DocScrutinizer05Dec 23 16:05:49 IroN900 mce[830]: Error when reading from /dev/input/event4: No such device
16:24.09Palihm... that input file is created after inserting headphones...
16:24.15DocScrutinizer05IOW would events in /dev/input/event* have timestamps?
16:24.40PaliI think input events have timestamps
16:24.52DocScrutinizer05then we're already done, no? :-D
16:25.23Palibut that input device reports only one thing
16:25.28DocScrutinizer05unless that input device has "debouncing" or shit
16:25.30Paliwhen headset button is pressed
16:25.38DocScrutinizer05ARRRRGH!
16:25.39Paliand it reports after 1s
16:25.45Paliuseless for now...
16:25.51DocScrutinizer05double-ARRRRGH!
16:26.02Palisee: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L106
16:26.05Palithis is that code
16:27.48DocScrutinizer05I see, it *does* >>"debouncing" or shit<<
16:28.12Palimaybe easier would be to patch nokia-av.c and recompile just nokia-av.ko
16:29.49Paliwhat all is needed?
16:30.09Paliwould not be easier to implement everything in that nokia-av.ko driver?
16:30.21DocScrutinizer05however 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*
16:30.53DocScrutinizer05yes, exactly what you said while I typed slowly
16:31.35DocScrutinizer05basically what we need is not much different to the debounce function there
16:31.39Paliok, after we decode it into bytes.. those bytes are then raw ECI protocol?
16:31.48DocScrutinizer05yes
16:32.02Paliok
16:32.22Paliand switching micbias on/off is other direction?
16:32.30DocScrutinizer05yes
16:32.53Palihm... so it needs correct timing
16:33.26Paliand is nokia-av.ko initializing ECI? or we need to implement it?
16:33.36PaliI see that nokia-av.ko already is doing with micbias
16:33.41Palisomething...
16:34.25DocScrutinizer05correct timing only really relevant intra-byte TX
16:35.00DocScrutinizer05I'd think the ECI protocil high level is really userland lib thing
16:35.37DocScrutinizer05incl initialization
16:36.21DocScrutinizer05no idea how HARM is doing it (or if at all)
16:36.55DocScrutinizer05I *think* N9/HARM knows and speaks ECI
16:37.29DocScrutinizer05they use a hw "UART" in TPS65951 that is absolutely undocumented
16:38.10DocScrutinizer05TI prolly inplemented it into TPS65951 on nokia's special request
16:38.15DocScrutinizer05for N9
16:39.22DocScrutinizer05now if only I hadn't killed my N9, I could test
16:39.40DocScrutinizer05waaait, I should also be able to test it on N950, no?
16:39.55Palimaybe yes
16:42.27PaliI think easy solution would be to add support for poll() syscall on /sys/devices/platform/nokia-av/eci0
16:42.32Paliand /sys/devices/platform/nokia-av/eci1
16:43.31Paliwhich are needed? both of them?
16:43.51DocScrutinizer05Oh Nokia F U!! N950 is AHJ
16:44.23DocScrutinizer05eci0 is needed
16:44.58Palieci1 too?
16:45.12DocScrutinizer05it doesn't even detect the headset when I plug it in
16:45.17DocScrutinizer05no
16:45.34DocScrutinizer05eci1 is for detection only
16:46.05DocScrutinizer05not related to ECI protocol
16:46.41Palihm... 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)
16:47.13DocScrutinizer05eci1 goes 0 whenever a jack with a mic impedance < ~8k Ohm gets plugged in
16:48.37DocScrutinizer05oops < 15k
16:50.24DocScrutinizer05http://wstaw.org/m/2016/12/23/plasma-desktopm17764.png 22k/(22k+6k8)=X/(X+4k7)
16:51.13DocScrutinizer05aka X=22k * (4k7/6k8)
16:52.28DocScrutinizer05also note that this only works when ECI5 switches mux to this comparator, and that disconnects micbias and replaces it by the 4k7 to 2V5
16:52.51DocScrutinizer05so a mere detector thing for detection phase after plugin
16:53.55DocScrutinizer05though of arguable value, given we also have madc
16:54.40DocScrutinizer05anyway not needed for ECI protocol
16:56.26VajbKotCzarny: i checked local auction sites and it seems that t500 and x220 r about the same price 150-300 depending of the seller...
16:56.54KotCzarnyx220 is a few gens higher
16:57.07KotCzarnyit would be like you were looking for t520 ;)
16:58.44Vajbinteresting that they r about the same price then
16:58.56KotCzarnysmaller is more expensive
16:59.02KotCzarnyusually
16:59.20Vajbx220 is smaller?
16:59.26KotCzarnyx series is ultraportable
16:59.42KotCzarnyt series is normal work machines
16:59.54Vajbt520 330e
17:00.00KotCzarnyforget 330e
17:00.11KotCzarnyhehe
17:00.35KotCzarnyunless they b0rk the series numbers, but afair it was like that always
17:00.50KotCzarnyie t60/x60, t500/x200
17:01.33KotCzarnyi got mine cheap when some company was upgrading from t500 laptops to t540
17:02.25Vajbyes. Im going to check one store which used to sell their old business laptops
17:03.13Vajblast time i visite there were some lenovo machines around 150e. Can't recall the number tho
17:03.17Vajbvisited*
17:03.41KotCzarnyi bught direct via local classifieds site, 2nd hand stores usually add their markup
17:03.48Vajbe series is low end i suppose?
17:04.01KotCzarnyyup, you only want t or x
17:04.18KotCzarnydepending if you want screen size or mobility
17:04.37KotCzarnyi dont remember if newer x series accomodated for dvd slot
17:04.51KotCzarnybut having it you can swap it for 2nd hdd, which is much more useful
17:05.06KotCzarnyin that case you want t series (or a dock)
17:05.30Vajbi saw docks for sale for 30e
17:05.47KotCzarnyfirst get a machine
17:06.13Vajbsure
17:06.33Vajbi suppose they come with win7 at least...
17:06.41Vajbi've had it with vista
17:06.46KotCzarnydepends, some with vista, some with win7
17:07.04KotCzarnyit was a switching period
17:07.13Vajbi c
17:08.46Vajband well vista eol will be next year anyway
17:09.25KotCzarnyyou can grab win7_64 boxed version, then install whenever you like
17:09.29DocScrutinizer05DAMN 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 :-/
17:11.01DocScrutinizer05still I don't get it why it doesn't work
17:11.13Vajboh t series is 64bit?
17:11.23KotCzarnymost core2duos are
17:11.38KotCzarnyif not all ;)
17:11.53Vajbi c
17:12.03KotCzarnyand you can always change the cpu
17:12.11KotCzarnyas its socketed (soldered in x)
17:13.02KotCzarnyyou should write all those requirements on your check-list
17:13.48Vajbi don't have much requirements :)
17:13.59Vajbi just have to be cheap and snappy
17:14.05Vajbit*
17:14.13KotCzarnyadd ssd to the list
17:14.35Vajboh yes that will kill the cheap bit
17:14.45KotCzarnyssd drives are reusable
17:14.57KotCzarnyyou can always move it from/to
17:15.16Vajbok i'll make some notes so t or x serie ssd
17:15.46KotCzarnyyou can get it with hdd and just buy ssd yourself (then move hdd to the bay)
17:15.48Vajbr they all core2duo because i think i saw some sold as i5?
17:16.17KotCzarnyt500 are from core2duo era, i think t510 or t520 was the first ones with intel iX
17:16.37KotCzarnyhttp://www.thinkwiki.org/wiki/Category:T_Series
17:16.49KotCzarnyyeah, all t500 are core2duo
17:17.01KotCzarnyt510 are i5/i7
17:17.08Vajbah i think they were some others then
17:17.13Vajbok
17:18.38KotCzarnywell, t4xx series are similar to t5xx, but using smaller screen
17:18.48KotCzarnyso you might hunt those too
17:18.58KotCzarny(14" vs 15")
17:19.51Vajbok, no versions with 17"?
17:20.11KotCzarnynot in the normal thinkpad series
17:20.51Vajbok i think i'll go with t series because my laptop just sits on the table always
17:22.59Vajbnext 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
17:23.15*** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net)
17:23.22KotCzarnyor just be patient and look for it in the nearest 6 months
17:23.25*** join/#maemo louis__ (~louisdk@static-5-103-130-65.seas-nve.net)
17:23.32KotCzarnyacer still works, so no rush
17:23.42Vajbyup, thx bbl
17:23.51KotCzarnyand you can put 10e/month into 'new laptop fund of vajb'
17:24.20Vajbhehe yeah
17:24.39Vajband acer works but vista not so much
17:24.45KotCzarnygo xp?
17:56.41KotCzarnyhttp://www.cnx-software.com/2016/12/23/25-nanopi-a64-is-a-compact-yet-features-packed-allwinner-a64-development-board/
17:56.46KotCzarnyum, wrong chan
18:04.12*** join/#maemo cyphase (~cyphase@unaffiliated/cyphase)
18:07.33*** join/#maemo spinal84 (~spinal@nat4-minsk-pool-46-53-176-225.telecom.by)
18:11.50*** join/#maemo pagurus (~user@x59cc8b2f.dyn.telefonica.de)
18:19.40Vajbis xp still supported?
18:20.03KotCzarnyi think there was some hack
18:21.34Vajbi'll see if i can find vista disk and try repair
18:22.13Vajbsfc found some weird registry issues
18:22.49KotCzarnyviree?
18:27.22Vajbumm come again?
18:27.31KotCzarnyvirus?
18:27.54Vajbshouldn't be
18:28.50Vajbi've used trendmicro house call + ms antivirus also two scanners for rootkits and three for malware
18:29.20KotCzarnyvista + 2 av programs? no wonder its slow as molasses
18:30.01Vajbtrendmicro is just online scanner which i use occasionally to get second opinion
18:30.31sicelo-what are you using xp for?
18:31.03Vajbsicelo-: it was just suggestion to replace vista
18:31.22Vajbi have vista which refuses to update itself
18:31.37sicelo-xp won't update at all :)
18:31.54KotCzarnybtw. that windows update fail also happens on w7
18:31.58Vajbso problem solved :p
18:31.59KotCzarnyit's m$ fault
18:32.37VajbKotCzarny: yes i know, but there is a tool to fix it from ms. Sadly it is not working under vista
18:33.04Vajbspeaking of "forcing users to switch"
18:33.15KotCzarnyi've had w7 systems stuck on 'checking for updates' no matter what i've tried
18:33.58Vajbthere 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
18:34.29KotCzarnyyup, there is a tool for w7 too. didnt work often
18:34.51sicelo-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 :-/
18:35.03Vajbi like cmd apt-get i can see what is happening that good looking knight rider rip off doesn't tell much
18:35.21KotCzarnysicelo: use lxde? or even fluxbox? or mate?
18:35.33KotCzarnyno need to reinstall, just switch DE
18:35.49sicelo-lxde vs. xfce .. whis is usually bette?
18:35.52KotCzarnyyou definitely want something light
18:35.56KotCzarnyboth are fine
18:36.12KotCzarnyso up to your liking
18:36.13sicelo-reinstall because i want to see if i 'solve' the hibernation issue
18:36.45sicelo-tbh both Gnome and KDE have been fine performance-wise on the X40 :)
18:36.58Vajbi think i've used both. Crunchbang has xfce i think
18:36.58sicelo-will look at fluxbox a bit more
18:37.17Vajbboth r too bloated for my system
18:38.06Vajbi like the feature that i can get to menu from anywhere on background
18:38.12sicelo-specs?
18:38.28Vajb1,3ghz amd tb
18:38.47Vajbaround 700mb of ram
18:39.23Vajbsome geforce 5x series agb display card
18:39.45KotCzarnytry fluxbox
18:40.36sicelo-mine is 1.4GHz, 1GB RAM, on-board graphics. i find gnome/kde perfectly useable. anyway, i am happy with N900 performance, so ... :)
18:40.42Vajbit is kind of sad that cpu power nowadays is "limitless"
18:40.54KotCzarnyits not ;)
18:40.54Vajbno one bothers to optimize
18:41.00Vajbespecially web pages
18:41.26Vajbmy puter used to be fine in flash6 time
18:41.39Vajbi could browse anything and watch the videos
18:41.40KotCzarnyi had 1ghz tb too
18:41.53KotCzarnystill have that cpu in the closet probably
18:43.12Vajbtake it in use
18:43.19Vajbplay with puppy linux
18:43.27KotCzarnyi can send it to you if you want
18:43.29KotCzarny:)
18:43.57Vajbi got laptop which had busted hdd so i installed puppy into usb memory and it was lightning fast
18:44.02KotCzarnyfor me it's only thinkpads + my gaming rig
18:44.22KotCzarnyand remember, i have and use and love my x40
18:44.35KotCzarnypentium-m single core @1.2ghz, 1.5gb ram
18:44.43Vajbyet another lenovo?
18:44.44KotCzarnyonly thing that makes it fly is hdd
18:44.46KotCzarnyssd i mean
18:44.50sicelo-same here
18:44.50KotCzarnynope. original ibm :P
18:45.00Vajboh i see
18:45.23sunshaviKotCzarny: You have more power than my compaq evo n600c
18:45.27sicelo-i would love to up the RAM to 1.5GB as well. currently have 1GB
18:45.28Vajbpentium m? Mobile? That low end processor serie?
18:45.59sicelo-Vajb: http://www.thinkwiki.org/wiki/Category:X40
18:46.06Vajbi'd love to have some 512mb sdram
18:46.21Vajbwas there ever 1024mb?
18:46.28KotCzarnyyup
18:46.52KotCzarnybase(soldered) 512megs, and 1gb module
18:46.55Vajboh so basically i could have 3gigs of memory 0.0
18:47.03*** join/#maemo cyphase (~cyphase@unaffiliated/cyphase)
18:47.10sicelo-i'm used to debian now (blame N900) ... what other distro could i try (not Ubuntu/Mint) ...
18:47.16Vajbmb has 3 slots
18:47.28KotCzarnysicelo: devuan?
18:47.44KotCzarnyif you like cmdline/scripts and doing most things by hand slackware
18:47.48Vajbsicelo-: try crunchbang follower
18:47.54Vajbcan't remember the name
18:47.59KotCzarnyif you like things compiled for your setup, gentoo
18:48.22sicelo-compiling on X40 .. sounds like fun :)
18:48.34KotCzarnyever heard of distcc? ;)
18:48.59sicelo-never looked at it in detail
18:49.15KotCzarnyessentially you need same gcc/g++ on other machine and network
18:49.49KotCzarnyand its like your compiling capabilities multiplied. but in case of x40 (single core) preprocessing takes most of the time
18:51.47KotCzarnyhmm, i might've lied about 1gb sdram (forgot x40 uses ddr1)
18:53.23Vajbwell actually i meant sdram sticks to my desktop ;)
18:53.35KotCzarnyyeah, that's what i meant
18:53.48KotCzarnythought x40 uses sdram (and i have 1gb stick in it)
18:53.59Vajbah i see
18:54.25Vajbi thin i have 256+256+128
18:54.35KotCzarnycheck if you can get x40/x60/x61 cheap enough
18:54.36Vajbthink too
18:56.44sicelo-verdict about Arch?
18:57.03sunshavisicelo: i am an arch user
18:57.32Vajbtried once long time ago didn't instantly fell in love
18:57.42sunshavinice for me, but when ready i am going to move to bsd for avoiding the systemd issue
18:57.59sunshaviI have more than 10 years using it.
18:58.22sunshaviBut distro is not important when using emacs. Distro is just a boot loader
18:59.12Vajbcare to buy vowel? BSOD
18:59.26DocScrutinizer05(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**!!!<<
19:00.33sicelo-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)
19:00.45DocScrutinizer05suggests swapping sleeve and center pin for RCA/Cinch jacks too, just "necause we can"
19:01.21sicelo-wonder if i shouldn't try slackware instead for now :-/
19:01.33sunshavinice thing about arch is pkgs are always up to date. so probably my way is going to be pacbsd
19:09.31KotCzarnysicelo, you dont have to reinstall, with linux you can have multiple systems on one drive
19:12.16sicelo-i don't have large HDD though
19:13.15KotCzarny8gb per os should be fine these days, unless specifically finetuned
19:37.36*** join/#maemo florian (~fuchs@Maemo/community/contributor/florian)
20:08.43*** join/#maemo cyphase (~cyphase@unaffiliated/cyphase)
20:10.26*** join/#maemo Oksanaa (~Oksanaa@Maemo/community/ex-council/Wikiwide)
20:12.42OksanaaAnybody got mscim to work? I installed mscimswitcher, mscim-hangul, mscim-tables-ja, and all I got is "mscim=no virtual keyboard"
20:14.02*** part/#maemo Oksanaa (~Oksanaa@Maemo/community/ex-council/Wikiwide)
21:00.49sicelo-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.
21:00.53sicelo-weird
21:03.36*** join/#maemo CraigEr (~quassel@79-67-28-31.dynamic.dsl.as9105.com)
21:54.43*** join/#maemo me (~me@104.244.77.140)
21:58.32*** join/#maemo me (~me@104.244.77.140)
22:04.00*** join/#maemo cyphase (~cyphase@unaffiliated/cyphase)
22:26.18*** join/#maemo XDS2010 (sid1218@gateway/web/irccloud.com/x-ykxgkrfwntlftygm)
23:03.12PaliDocScrutinizer05: https://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power;a=commit;h=0533144967fcf0cc4e485cf40e586140e7a1d960
23:03.28Paliwe already have this patch in kp53
23:03.50Paliwhich via that input device report *immediately* state of eci0 gpio when changed
23:03.54Palihttps://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power;a=blob;f=kernel-power-2.6.28/debian/patches/nokia-av_key.patch
23:04.48Paliit is called at begining of that irq handler for eci0
23:07.06Paliso via poll() on that /dev/input/ device (created after plugging headset; disappear after unplugging) you can wait for events
23:09.16*** join/#maemo geaaru_ (~geaaru@host214-223-dynamic.250-95-r.retail.telecomitalia.it)
23:10.30Paliand /dev/input device events contains timestamp!
23:10.54Palistruct input_event { struct timeval time; __u16 type; __u16 code; __s32 value; }
23:11.00Palithis is structure which send
23:12.40Palitype is EV_KEY (0x01); code is KEY_PROG1 (148); value is boolean negation of eci0 gpio state
23:13.04Paliif input subsystem is fast enough we do not need any kernel patching!
23:13.53DocScrutinizer05yes! great :-))
23:15.08DocScrutinizer05actually only needs to be "fast enough" to get timestamp and handle forward it before next IRQ after 80us comes in
23:16.41Palido you need to process eci0 realtime, or is "buffered" enough with correct timestamp?
23:17.04Palie.g. if you get ten events at once, but with timestamp
23:18.14DocScrutinizer05the 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
23:18.56DocScrutinizer05even 32 or 40 events with timestamp are fine when just buffered
23:19.53Palithis needs experiment if input layer is enough or not
23:19.54DocScrutinizer05it seems no reply sent by headset is longer a burst than 2 bytes
23:20.59DocScrutinizer05after 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
23:21.21DocScrutinizer0518 bits = 36 events
23:22.22DocScrutinizer05analyze*
23:23.17DocScrutinizer0536 events -> 2 bytes ==>/dev/eci or dbus-signal or whatever
23:24.42DocScrutinizer05communication 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
23:25.21DocScrutinizer05time until respinse or next command isn't critical aiui, it may take several dizen milliseconds
23:25.38DocScrutinizer05God!
23:25.48DocScrutinizer05time until response or next command isn't critical aiui, it may take several dozen milliseconds
23:31.32DocScrutinizer05afaik (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
23:31.33DocScrutinizer05ACK a few ms later
23:33.26Paliand must device start session immediately after plug-in? or can be it e.g. 10sec after plug-in?
23:33.52Palibecause it takes some time after udev create /dev/input device after plug-in
23:37.15*** join/#maemo erstazi_ (~erstazi@unaffiliated/erstazi)
23:37.31DocScrutinizer05I think the session gets started by 4ms of low pulse
23:37.35DocScrutinizer05at any time
23:37.57Paliand session is started by device? or by headset?
23:38.03DocScrutinizer05by device
23:38.25Paliok, then slow udev and creating input device should not be a problem
23:38.51DocScrutinizer05http://neo900.org/stuff/joerg/ECI/init/
23:39.28DocScrutinizer05http://neo900.org/stuff/joerg/ECI/init/ECI_init01_ph4ms_low_hsA2pulses.jpg
23:39.48DocScrutinizer05og, HS answers with TWO startbit
23:39.54DocScrutinizer05oh*
23:41.07DocScrutinizer05note how the HS pulses have a lower low voltage (hard to see but it's there)
23:41.42DocScrutinizer05and HS pulses also have that tiny bright line at beginning of falling edge
23:43.06DocScrutinizer05in 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
23:43.20DocScrutinizer05after 4.x ms
23:43.40DocScrutinizer05I'm sure those 4.x ms are not critical
23:44.40DocScrutinizer05http://neo900.org/stuff/joerg/ECI/init/ECI_init02_phCMD_identify.jpg is the IDENTIFY command shifted into screen from right
23:46.15DocScrutinizer05HS replies by http://neo900.org/stuff/joerg/ECI/init/ECI_init03_hsANSWER_ident.jpg
23:46.25Palianyway, how is that defaul n900 headset with button working?
23:46.33Paliit is ECI? or different protocol?
23:46.40DocScrutinizer05and sorry I was wrong, those seem to be 4 byte
23:47.31DocScrutinizer05default has no damn clue about boolean logic, it siply shirts MICBIAs to GND as long as you press the button
23:47.54DocScrutinizer05simply shorts*
23:48.20DocScrutinizer05so basically it sends a veeeeeery long "ECI oulse"
23:48.35DocScrutinizer05pulse. sorry can't type anymore
23:51.15DocScrutinizer05re high level protocol, I guess you can find all the gory details in the existing sourcecode
23:52.12DocScrutinizer05https://lwn.net/Articles/420775/ etc
23:55.29DocScrutinizer05as 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
23:56.49DocScrutinizer05iirc 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

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.