*** florian has quit IRC | 00:19 | |
*** flo_lap is now known as florian | 00:19 | |
*** florian_kc has joined #maemo | 00:19 | |
*** pagurus has quit IRC | 00:48 | |
*** Pali has quit IRC | 00:49 | |
*** Kilroo has quit IRC | 01:02 | |
DocScrutinizer05 | http://neo900.org/stuff/joerg/ECI/ with full 12Mpts init log (rigol.wfm) | 01:09 |
---|---|---|
*** louis__ has quit IRC | 01:10 | |
*** louisdk has quit IRC | 01:10 | |
*** RzR has quit IRC | 02:05 | |
*** RzR has joined #maemo | 02:06 | |
*** L29Ah has joined #maemo | 02:10 | |
*** florian has quit IRC | 02:23 | |
*** florian has joined #maemo | 02:32 | |
*** peterbjornx has joined #maemo | 02:35 | |
*** florian has quit IRC | 02:41 | |
*** peterbjornx has quit IRC | 02:52 | |
*** agomez{M} has quit IRC | 03:02 | |
*** platicus has quit IRC | 03:02 | |
*** agomez{M} has joined #maemo | 03:04 | |
*** platicus has joined #maemo | 03:04 | |
*** peterbjornx has joined #maemo | 03:04 | |
*** platicus has quit IRC | 03:06 | |
*** agomez{M} has quit IRC | 03:06 | |
*** platicus has joined #maemo | 03:06 | |
*** agomez{M} has joined #maemo | 03:06 | |
*** Kabouik_ has joined #maemo | 03:13 | |
*** dafox has joined #maemo | 03:14 | |
*** platicus has quit IRC | 03:15 | |
*** agomez{M} has quit IRC | 03:15 | |
*** platicus has joined #maemo | 03:15 | |
*** agomez{M} has joined #maemo | 03:15 | |
*** Kabouik has quit IRC | 03:16 | |
*** L29Ah has left #maemo | 03:19 | |
_maniac_ | rip my n900, left as temporary pawn for taxi driver who just sprinted off without waiting for money. | 03:20 |
_maniac_ | I guess he'll enjoy my gentoo chroot there. | 03:20 |
*** _maniac_ has left #maemo | 03:20 | |
*** L29Ah has joined #maemo | 03:20 | |
*** dafox has quit IRC | 03:37 | |
*** RzR has quit IRC | 04:02 | |
*** RzR has joined #maemo | 04:02 | |
*** peterbjornx has quit IRC | 04:29 | |
*** robink_ has quit IRC | 04:37 | |
*** robink has joined #maemo | 04:43 | |
*** e has joined #maemo | 04:47 | |
*** Kilroo has joined #maemo | 05:29 | |
*** florian__ has joined #maemo | 05:33 | |
*** florian_kc has quit IRC | 05:37 | |
*** lxp1 has joined #maemo | 06:01 | |
*** lxp has quit IRC | 06:04 | |
*** DocScrutinizer05 has quit IRC | 07:34 | |
*** DocScrutinizer05 has joined #maemo | 07:34 | |
*** CatButts has joined #maemo | 08:40 | |
*** TheKit has quit IRC | 09:14 | |
*** TheKit has joined #maemo | 09:18 | |
*** Pali_ has joined #maemo | 09:47 | |
*** geaaru has joined #maemo | 09:55 | |
sixwheeledbeast | Maybe would have been better to pawn your leg, at least you have another one... | 09:57 |
bencoh | :/ | 09:58 |
KotCzarny | i think he left already | 09:58 |
KotCzarny | but friggin taxi driver stealing n900? the hell with the world we live in | 09:58 |
xes | someone was a bit drunken...or both of them | 09:59 |
*** Pali_ is now known as Pali | 10:04 | |
*** troulouliou_div2 has joined #maemo | 10:09 | |
*** heroux has quit IRC | 10:27 | |
*** heroux has joined #maemo | 10:27 | |
*** ShadowJK has joined #maemo | 10:34 | |
*** florian__ is now known as florian | 10:39 | |
*** ecloud is now known as ecloud_wfh | 11:01 | |
*** troulouliou_div2 has quit IRC | 11:10 | |
*** krnlyng has quit IRC | 11:19 | |
*** shentey has joined #maemo | 11:21 | |
DocScrutinizer05 | http://neo900.org/stuff/joerg/ECI/all_buttons/ | 11:22 |
*** troulouliou_div2 has joined #maemo | 11:26 | |
DocScrutinizer05 | for N900 bitbang outbound data with SoC TVOUT_EN while TVOUT set to GPIO-OUT:GND/low | 11:27 |
*** troulouliou_div2 has quit IRC | 11:29 | |
DocScrutinizer05 | to read inbound, use ECI_AD and/or comparator N4008:ECI1:GPMC_nWP-H1 and/or N4007:ECI0:GPMC_nBE1-H3 | 11:31 |
DocScrutinizer05 | particularly the latter seems very suited | 11:32 |
*** krnlyng has joined #maemo | 11:32 | |
DocScrutinizer05 | prolly already also used to detect holdbutton-press | 11:34 |
DocScrutinizer05 | ECI is basically just holdbutton fast morse ;-) | 11:34 |
DocScrutinizer05 | such software solution will be 100% compatible to Neo900 too | 11:37 |
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 | 11:40 |
*** L29Ah has left #maemo | 11:40 | |
DocScrutinizer05 | for TX a realtime scheduled userland task might do | 11:41 |
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 | 11:42 |
DocScrutinizer05 | and even when a higher prio system interrupt will eventually mess up a burst, nothing too bad will happen | 11:44 |
DocScrutinizer05 | just make sure to disable your own RX IRQs during TX ;-) | 11:44 |
DocScrutinizer05 | well, for TWOUT_EN they won't even fire on hw level, so that's no issue | 11:45 |
DocScrutinizer05 | TV* | 11:45 |
DocScrutinizer05 | bota bene: without proper initialization a ECI headset will "act dead" | 11:46 |
DocScrutinizer05 | nota, even | 11:46 |
DocScrutinizer05 | atk: ^^^ how about that? ;-) | 11:47 |
DocScrutinizer05 | Pali: you also might be mildly interested | 11:47 |
DocScrutinizer05 | Pali: except for the "PHY layer" the solution is pretty platform agnostic | 11:48 |
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) | 11:50 |
DocScrutinizer05 | worst case you can emulate the latter via ALSA record ;-) | 11:50 |
*** louisdk has joined #maemo | 11:56 | |
*** louis__ has joined #maemo | 11:56 | |
DocScrutinizer05 | s/ TV_OUT / TVOUT_EN / 2 above | 12:08 |
DocScrutinizer05 | hint: TVOUT_EN = GPIO40 | 12:12 |
DocScrutinizer05 | http://neo900.org/stuff/joerg/ECI/scopeshots/ECI_NOT__N900_plugin_for_reference.jpg | 12:27 |
atk | DocScrutinizer05: https://lwn.net/Articles/420775/ | 12:54 |
*** troulouliou_div2 has joined #maemo | 12:54 | |
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 | 12:55 |
atk | DocScrutinizer05: if anything, that can be used as a base, I'll try to work out why it was never accepted | 12:55 |
atk | I see | 12:55 |
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) | 12:58 |
atk | It's weird, when I google "ECI" or "Enhancement Control Interface" I get nothing relevantz | 12:59 |
atk | s/z$// | 13:00 |
DocScrutinizer05 | well, except this is a screenshot of a HS reply, so you rather see a ECIread() == 0b00100000; ECIread() == 0b00000000; | 13:00 |
atk | I see | 13:00 |
DocScrutinizer05 | yeah, there is *very* little publicly available docs anout ECI | 13:01 |
*** troulouliou_div2 has quit IRC | 13:01 | |
atk | So these inline controls in earphones actually have logic in them? | 13:01 |
DocScrutinizer05 | yes | 13:01 |
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 | 13:02 |
DocScrutinizer05 | yes, single wire bidir serial | 13:02 |
DocScrutinizer05 | well, they use the same for e.g SIM data, for battery embedded gas gauges (bq27000, HDQ protocol) and whatnot else | 13:04 |
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? | 13:04 |
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 | 13:05 |
DocScrutinizer05 | don't you have a N900? | 13:05 |
DocScrutinizer05 | a N900 will work excellent for this | 13:06 |
DocScrutinizer05 | while on BeagleBoard the hardware is missing | 13:06 |
atk | I see | 13:06 |
atk | so N900 does this in software too? | 13:06 |
DocScrutinizer05 | ~schematics | 13:06 |
infobot | i heard schematics is http://wiki.maemo.org/N900_Hardware_Schematic | 13:06 |
DocScrutinizer05 | N900 doesn't do this so far, that's the point | 13:07 |
DocScrutinizer05 | :-) | 13:07 |
DocScrutinizer05 | it *could* do it with the right software | 13:07 |
atk | Ah, cool | 13:08 |
DocScrutinizer05 | my tests are done with a N97-mini and a genuine (inknown type) Nokia multibutton headset | 13:08 |
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. | 13:11 |
DocScrutinizer05 | ~literal schematics | 13:12 |
infobot | "schematics" is "http://wiki.maemo.org/N900_Hardware_Schematic" | 13:12 |
DocScrutinizer05 | ~schematics is also http://www.google.de/search?q=nokia+n900+rx-51+schematics.pdf&oq=Nokia_N900_RX-51_schematics | 13:12 |
infobot | okay, DocScrutinizer05 | 13:12 |
DocScrutinizer05 | http://wstaw.org/m/2016/12/23/plasma-desktopN17764.png | 13:13 |
DocScrutinizer05 | http://maemo.cloud-7.de/share-service/20161222_002.jpg my test setup | 13:15 |
*** LauRoman has quit IRC | 13:15 | |
DocScrutinizer05 | (without scope probe attached yet, goes to the yellow clip) | 13:15 |
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 | 13:17 |
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 | 13:19 |
DocScrutinizer05 | http://neo900.org/stuff/joerg/ECI/init/ECI_init00.png http://neo900.org/stuff/joerg/ECI/init/ECI_init01_ph4ms_low_hsA2pulses.jpg | 13:21 |
DocScrutinizer05 | note how in the latter the two short pulses after the 4ms intitial one are from HS, they are lower voltage | 13:21 |
DocScrutinizer05 | and have that tiny "mark" on beginning of falling edge: http://wstaw.org/m/2016/12/23/plasma-desktopc17764.png | 13:23 |
DocScrutinizer05 | which in fact is the initial slight voltage drop to be seen in http://neo900.org/stuff/joerg/ECI/scopeshots/ECIpulseHS.jpg | 13:23 |
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) | 13:28 |
DocScrutinizer05 | the sigle bit seems to be encoded as either 1 low 4 high (unit 100us?) or 4 low 1 high | 13:29 |
DocScrutinizer05 | err sorry, rather it's 4h1l or 1h4l | 13:30 |
DocScrutinizer05 | startbit is 4h1l it seems | 13:30 |
DocScrutinizer05 | you don't see the leading 4h since the line is h all the time when inactive | 13:31 |
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 | 13:33 |
*** LauRoman has joined #maemo | 13:42 | |
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 | 13:42 |
DocScrutinizer05 | I'd expect you find a "IDENTIFY" (owtte) command in the existing ECI sources, of a value like 0x0f00 or 0xf0ff | 13:43 |
DocScrutinizer05 | oops sorry, I slipped | 13:46 |
DocScrutinizer05 | startbit(1) [data]00001111 >>WHATSTHIS???(1timeunit-h,1timeunit-l)=startbit_with shirt-hightime?(1)<< [data]01011010 <finish> | 13:48 |
DocScrutinizer05 | so a value like 0x0f5a or 0xf0a5 | 13:50 |
DocScrutinizer05 | let's define startbit=100us-high + 100us-low; bit1= 400us-high + 100us-low; bit0= 100us-high + 400us-low --- just as a working hypothesis | 13:53 |
DocScrutinizer05 | and data frame format = 1 startbit, 8 data bits, no stop bit | 13:54 |
DocScrutinizer05 | hmm, make that 80us and 320us | 13:56 |
DocScrutinizer05 | doesn't matter I guess. And easy to tune in source later on | 13:57 |
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) | 14:02 |
DocScrutinizer05 | IroN900:~# find /sys -iname '*eci*' | 14:03 |
DocScrutinizer05 | /sys/devices/platform/nokia-av/eci0 | 14:03 |
DocScrutinizer05 | /sys/devices/platform/nokia-av/eci1 | 14:03 |
DocScrutinizer05 | /sys/devices/platform/soc-audio/eci_mode | 14:03 |
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 ;-) | 14:08 |
DocScrutinizer05 | so what you want to read is /sys/devices/platform/nokia-av/eci1 | 14:08 |
DocScrutinizer05 | or rather monitor with your IRQ handler | 14:09 |
DocScrutinizer05 | of course for a mere POC you could also poll with a period of 80us | 14:10 |
DocScrutinizer05 | hmm, prolly rather 50us | 14:11 |
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) | 14:18 |
DocScrutinizer05 | real 0m0.593s | 14:18 |
DocScrutinizer05 | so this thing already polls @ 70us | 14:20 |
DocScrutinizer05 | should be able to read out a HS response raw data (to a real file instead of /dev/null) | 14:20 |
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 | 14:22 |
*** auenf has quit IRC | 14:27 | |
*** auenf has joined #maemo | 14:27 | |
*** Konsieur has joined #maemo | 14:30 | |
DocScrutinizer05 | IroN900:/sys/devices/platform/nokia-av# time (for (( i=0; i<1000; i++ )); do read r <eci0; echo -n "$r:"; done >/dev/null) | 14:30 |
DocScrutinizer05 | real 0m0.546s | 14:30 |
*** Kabouik_ has quit IRC | 14:33 | |
*** shentey has quit IRC | 14:47 | |
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 | 14:53 |
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 | 14:56 |
Pali | so it change RX51_ECI_SWITCH_1_GPIO and RX51_ECI_SWITCH_2_GPIO gpios | 14:57 |
Pali | #define RX51_ECI_SWITCH_1_GPIO178 | 14:57 |
Pali | #define RX51_ECI_SWITCH_2_GPIO182 | 14:57 |
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 | 15:02 |
DocScrutinizer05 | puzzling results are: ECI0 always "0" while detect goes "4" -> "2" when pressing the hold button | 15:04 |
*** spinal84 has quit IRC | 15:04 | |
DocScrutinizer05 | and even madc is always at around 4 or 5 | 15:04 |
DocScrutinizer05 | I already thought my headset was defect until I noticed the detect value change | 15:05 |
Pali | no, nobody in Maemo is doing anything with eci_mode sysyfs | 15:05 |
Pali | at least not in stock PR1.3 | 15:05 |
DocScrutinizer05 | then those nodes provide not at all what their names suggest | 15:06 |
Pali | grepped rootfs of PR1.3 /mnt/n900/{bin,lib,sbin,usr/lib,usr/bin,usr/sbin} | 15:06 |
DocScrutinizer05 | madc=4 means what? a 100mV on micbias? | 15:07 |
Pali | ADCIN4 - Battery size indicator | 15:08 |
DocScrutinizer05 | and even if that was true, how the heck does "detect" notice holdbutton press while madc doesn't change value? | 15:08 |
DocScrutinizer05 | not ADCIN4 | 15:08 |
DocScrutinizer05 | /sys/devices/platform/nokia-av/madc | 15:09 |
Pali | look: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L280 | 15:09 |
DocScrutinizer05 | value = 4 | 15:09 |
Pali | that madc sysfs returns value fomr ADCIN2 | 15:10 |
Pali | ADCIN2 - ECI AD | 15:10 |
Pali | and that value = 4 is RAW value | 15:11 |
Pali | mV = RAW * 147 / 60 | 15:11 |
DocScrutinizer05 | ~4*147/50 | 15:13 |
infobot | 11.76 | 15:13 |
Pali | so it is 9.8mV | 15:13 |
Pali | ~4*147/60 | 15:13 |
infobot | 9.8 | 15:13 |
DocScrutinizer05 | doesn't make sense | 15:13 |
DocScrutinizer05 | madc is always 4 or 5 no matter if I push holdbutton or not | 15:14 |
DocScrutinizer05 | so whatever `cat /sys/devices/platform/nokia-av/madc` shows, it's quite evidently not the voltage on mic line of AV jack | 15:15 |
*** zGrr has joined #maemo | 15:16 | |
Pali | do you have mic bias enabled? | 15:17 |
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 | 15:17 |
Pali | because alsaped maemo daemon is automatically disabling it when headset is plugged | 15:17 |
Pali | ok, going to test | 15:17 |
DocScrutinizer05 | Pali: it detects holdbutton press, and holdbutton shorts micbias to GND | 15:17 |
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 | 15:18 |
DocScrutinizer05 | http://paste.opensuse.org/40688624 | 15:19 |
DocScrutinizer05 | stock kernel here! | 15:20 |
DocScrutinizer05 | with CSSU | 15:21 |
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 | 15:23 |
DocScrutinizer05 | madc not changing at all while value of detect changes with holdbutton status indicated madc is bogus | 15:24 |
DocScrutinizer05 | I'd also expect eci0 to be 1 as long as hold button not pressed. It's always 0 | 15:25 |
DocScrutinizer05 | conclusion: kernel driver fubar | 15:26 |
DocScrutinizer05 | eci is 1 as long as no hs plugged at all | 15:26 |
DocScrutinizer05 | sth is fuxored there | 15:27 |
Pali | madc here is about 68 | 15:31 |
DocScrutinizer05 | ohmmy! I guess I know what's happening. I suspect `cat detect` enables micbias, checks button status, and disables micbias again | 15:31 |
Pali | and sometimes when I push button then madc is 135 | 15:31 |
Pali | but just sometimes | 15:31 |
DocScrutinizer05 | I wondered why the cmdline takes that looooong | 15:32 |
Pali | and if I start pressing button to quick madc goes above 210 | 15:32 |
DocScrutinizer05 | o.O | 15:32 |
DocScrutinizer05 | that's not ok for sure | 15:32 |
KotCzarny | some counter? | 15:32 |
Pali | see what is cat detect doing: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L280 | 15:33 |
Pali | it changes those GPIOs | 15:33 |
DocScrutinizer05 | with headset unplugged, my madc is at 1024 around | 15:33 |
KotCzarny | check if it changes with the rate you are pressing | 15:33 |
DocScrutinizer05 | Pali: so quite possibly my micbias is NOT enabled all the time | 15:34 |
DocScrutinizer05 | Pali: and it seems yours isn't as stable as it's supposed to be, as well | 15:35 |
DocScrutinizer05 | the dependency on push speed is from R-C charging of micbias voltage buffer cap | 15:35 |
Pali | bah!! cat detect disable mic bias | 15:36 |
Pali | see alsamixer -c 0 | 15:36 |
DocScrutinizer05 | something's totally messed up in there | 15:36 |
DocScrutinizer05 | yes, see what I said above: obviously cat detect enables micbias to run the tests and then disables it again | 15:36 |
Pali | now when mic bias is always enabled, then madc is about 317 | 15:37 |
Pali | and when I press button it is about 68 | 15:37 |
DocScrutinizer05 | now that makes sense :-) | 15:37 |
DocScrutinizer05 | how would I enable micbias? | 15:38 |
Pali | alsamixer -c 0 | 15:38 |
DocScrutinizer05 | ta | 15:38 |
Pali | and find "jack bias" | 15:38 |
Pali | and use 'm' key | 15:38 |
Pali | to switch between on/off | 15:38 |
KotCzarny | oscp uses micbias to detect button presses on nokia headsets | 15:39 |
KotCzarny | s/micbias/jack bias/ | 15:39 |
infobot | KotCzarny meant: oscp uses jack bias to detect button presses on nokia headsets | 15:39 |
DocScrutinizer05 | amixer -c 0 scontrols|grep -i bias | 15:39 |
Pali | looks like nobody in maemo is accessing /sys/devices/platform/nokia-av/detect | 15:40 |
Pali | (only /usr/lib/testserver/modules/handlers/selftests.so.0) | 15:40 |
Pali | (but whole testserver is irrelevant there as it is not running in normal Maemo) | 15:41 |
Pali | ~65*147/60 | 15:41 |
infobot | 159.25 | 15:41 |
Pali | ~317*147/60 | 15:42 |
infobot | 776.65 | 15:42 |
Pali | hm... so 160mV and 780mV? | 15:42 |
DocScrutinizer05 | amixer -c 0 cset name='Jack Bias Switch' 1 | 15:44 |
Pali | yes | 15:45 |
DocScrutinizer05 | http://paste.opensuse.org/38383984 | 15:45 |
Pali | anyway, CSSU in some version automatically enable jack bias after inserting headset with mic | 15:45 |
DocScrutinizer05 | DAMMIT! phonecall, no audio. I guess it tried to use a headset thats not there | 15:47 |
DocScrutinizer05 | :-/ | 15:48 |
DocScrutinizer05 | I should start to use a test device for such experiments again | 15:48 |
*** louisdk has quit IRC | 15:54 | |
*** louis__ has quit IRC | 15:54 | |
DocScrutinizer05 | Pali: do you know what autodetect sysnode does? | 16:15 |
DocScrutinizer05 | in /sys/devices/platform/nokia-av/autodetect | 16:15 |
Pali | yes, it just control variable autodetect | 16:17 |
Pali | and that is used only here: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L456 | 16:17 |
Pali | when set to zero then that headph_handler is noop | 16:17 |
*** L29Ah has joined #maemo | 16:19 | |
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 | 16:19 |
*** florian has quit IRC | 16:20 | |
Pali | I updated https://wiki.maemo.org/Porting/Kernel#Porting | 16:20 |
Pali | now cssu can boot without /proc/bootreason and /dev/twl4030-adc | 16:21 |
DocScrutinizer05 | plug-cycled, NOW we're talking! :) http://paste.opensuse.org/83643851 | 16:22 |
DocScrutinizer05 | Pali: (cssu) excellent, that stuff is pretty much pointless, particularly the twl4030-adc for BSI test battery | 16:23 |
Pali | we need to also get rid off /proc/component_version and /sys/class/gpio-swich | 16:24 |
DocScrutinizer05 | I *guess* bootreason makes some sense for deciding if to re-use an existing PIN or ask for it again | 16:24 |
Pali | I mean, maemo cssu can boot without those files | 16:25 |
Pali | if files are provided they are used | 16:25 |
DocScrutinizer05 | meh /proc/component_version | 16:25 |
DocScrutinizer05 | what the heck?! | 16:26 |
Pali | if not, then fallback mechanism is used (e.g. /proc/cpuinfo or /proc/atags) or hardcoded strings, eg. bootreason is pwr_key | 16:26 |
DocScrutinizer05 | compiled in to kernel (DT?) | 16:26 |
Pali | component version is key/value file | 16:26 |
Pali | with data from NOLO | 16:26 |
Pali | passed via ATAGs | 16:26 |
DocScrutinizer05 | ohmy | 16:26 |
DocScrutinizer05 | ATAGs my headache | 16:27 |
Pali | and nolo pass just: board name, hw revision, nolo version and boot mode | 16:27 |
Pali | and boot mode is either "normal" or "update" | 16:27 |
Pali | and some rcS script check for "update" and enter into different runlevel | 16:27 |
DocScrutinizer05 | I wonder how hard it could get to completely replace NOLO by uboot | 16:27 |
Pali | when just softup via usb is running | 16:28 |
Pali | already tried to replace NOLO with uboot | 16:28 |
Pali | and I failed | 16:28 |
DocScrutinizer05 | yeah I know | 16:28 |
DocScrutinizer05 | wonder why, though | 16:28 |
Pali | 1. problem is size 100kB | 16:28 |
DocScrutinizer05 | ugh | 16:28 |
Pali | uboot is big :-( | 16:28 |
Pali | 2. problem uboot has broken onenand support (or had in ~~ 2012) | 16:29 |
DocScrutinizer05 | doubleplusugh | 16:29 |
Pali | 3. problem uboot has broken omap3 usb | 16:29 |
DocScrutinizer05 | ohmy | 16:29 |
Pali | 4. problem no idea which hw initialization is needed to implement | 16:30 |
DocScrutinizer05 | sounds nasty | 16:30 |
Pali | we have no idea what it is doing... probably some SSI/modem init is needed too... | 16:30 |
DocScrutinizer05 | isn't there a working uboot for pandora and beagleboard? | 16:31 |
DocScrutinizer05 | oooh modem init | 16:31 |
Pali | and at that time in uboot was no support for spi... so no display init code | 16:31 |
DocScrutinizer05 | ouch | 16:31 |
Pali | pandora and beagleboard is probably working fine with uboot | 16:31 |
Pali | but thse do not have nokia's SSI modem | 16:31 |
DocScrutinizer05 | yeah sure | 16:32 |
Pali | uboot is working fine on n900, just it needs to be loaded by nolo :-) | 16:32 |
DocScrutinizer05 | but... the modem should get initialized only lated, by kernel | 16:32 |
DocScrutinizer05 | later* | 16:32 |
KotCzarny | glue uboot to nolo | 16:32 |
KotCzarny | or nolo to uboot | 16:32 |
Pali | nolo can flash fw for modem... | 16:32 |
Pali | so there is big blob in nolo for that | 16:33 |
DocScrutinizer05 | eeek | 16:33 |
Pali | and no idea if some init is really not needed... | 16:33 |
Pali | KotCzarny: see first problem about size | 16:33 |
DocScrutinizer05 | are you sure modem flashing done by nolo? | 16:33 |
Pali | either by nolo or via some RPC | 16:33 |
DocScrutinizer05 | I thought it's done along softupd foo | 16:34 |
Pali | softupd can do that | 16:34 |
Pali | but nolo too! | 16:34 |
DocScrutinizer05 | incredible | 16:34 |
Pali | and via usb cable to flasher-3.5 nolo exports some strange protocol for modem flashing status | 16:34 |
DocScrutinizer05 | I see | 16:35 |
Pali | which is different from other notification | 16:35 |
DocScrutinizer05 | yep, of course. It's Nokia shit | 16:35 |
Pali | every status information to flasher-3.5 has one format, just modem flashing status has different | 16:35 |
DocScrutinizer05 | F-Bus | 16:35 |
Pali | it is string based (for flasher-3.5) | 16:35 |
Pali | but some f-bus is probably used in nolo and softupd | 16:36 |
DocScrutinizer05 | this? http://shodhganga.inflibnet.ac.in/bitstream/10603/64948/9/09_chapter 3.pdf | 16:36 |
DocScrutinizer05 | possibly for flashing even M-Bus, not F-Bus | 16:38 |
Pali | going to look at that protocol | 16:39 |
DocScrutinizer05 | http://mennucc1.debian.net/lacie_network_space/nokia-ca-42/Embedtronics - Nokia F-Bus Protocol made simple.html | 16:39 |
Pali | and compare it with what I sniffed and implemented in 0xFFFF | 16:39 |
Pali | no, protocol is totally different | 16:41 |
DocScrutinizer05 | http://wiki.gnokii.org/index.php/MBUS_protocol | 16:41 |
DocScrutinizer05 | check Phoenix flashers | 16:41 |
DocScrutinizer05 | http://www.allmobiletools.net/2014/12/nokia-phoenix-service-software-201415.html | 16:42 |
DocScrutinizer05 | sorry for the useless link | 16:42 |
DocScrutinizer05 | https://nokiarevolution.com/how-to-flash-your-nokia-device-via-phoenix-usb-dead-flashing/ | 16:43 |
DocScrutinizer05 | not much info but for sure the right protocol we're looking for | 16:44 |
DocScrutinizer05 | *all* nokia phones use that protocol | 16:44 |
Pali | what softupd thing uses different protocool | 16:44 |
DocScrutinizer05 | either via serial (M-bus, F-bus, whatever) or via USB with some wrapper protocol aiui | 16:44 |
Pali | see: https://github.com/pali/0xFFFF/blob/master/doc/mkii | 16:45 |
DocScrutinizer05 | yeah softupd is not using phoenix protocol, they use something they made up for maemo | 16:45 |
DocScrutinizer05 | I however bet they embedded the phoenix protocol into softupd for BB5-modem flashing | 16:46 |
Pali | anyway, phoenix IIRC uses same protocol for n900 | 16:46 |
Pali | and it uses that testserver | 16:46 |
DocScrutinizer05 | quite possible, yes | 16:47 |
DocScrutinizer05 | BSI crap | 16:47 |
DocScrutinizer05 | "lab battery" | 16:47 |
Pali | I have some information that FIASCO format is some BB5 format | 16:48 |
DocScrutinizer05 | oooh | 16:50 |
DocScrutinizer05 | at least that explains CAL | 16:50 |
DocScrutinizer05 | CAL looks *very much* like invented for modem "filesystem" | 16:51 |
DocScrutinizer05 | and this is what Phoenix modifies for stuff like ALS calibration etc | 16:52 |
Pali | it uses testserver for that | 16:52 |
Pali | and testserver has plugin for als | 16:52 |
DocScrutinizer05 | quite possible | 16:52 |
Pali | so this probably access CAL | 16:52 |
Pali | IIRC nolo does not export any access to CAL over usb | 16:52 |
Pali | I already tried to do anything... | 16:53 |
Pali | also no "backup" support seems to be in NOLO | 16:53 |
DocScrutinizer05 | yeah, no Nokia phone has that, prolly considered a security feature | 16:59 |
DocScrutinizer05 | anyway seems ECI0 is working like supposed, when enabling micbias. So would you know how to control TVOUT_EN? | 17:00 |
Pali | in sound/soc/omap/rx51.c is: #define RX51_TVOUT_SEL_GPIO40 | 17:05 |
Pali | it is this gpio? | 17:05 |
DocScrutinizer05 | yes | 17:07 |
Pali | that is exported to alsa | 17:07 |
DocScrutinizer05 | ouch | 17:08 |
Pali | RX51_JACK_TVOUT | 17:08 |
DocScrutinizer05 | much overhead to toggle itt | 17:08 |
Pali | when rx51_jack_func is RX51_JACK_TVOUT then RX51_TVOUT_SEL_GPIO is set to 1 | 17:08 |
Pali | otherwise to 0 | 17:08 |
Pali | but should be possible to control it via /sys/class/gpio | 17:09 |
Pali | as any other gpio | 17:09 |
DocScrutinizer05 | I want to create 0.8ms pulses on this GPIO | 17:09 |
DocScrutinizer05 | err 0.08ms | 17:10 |
DocScrutinizer05 | I can poll eci0 with almost 2000/s | 17:10 |
Pali | bah, linux kernel refuse to export it :-( | 17:11 |
Pali | # echo 40 > /sys/class/gpio/export | 17:11 |
Pali | bash: echo: write error: Device or resource busy | 17:11 |
Pali | probably because that alsa driver already has it for its own | 17:12 |
DocScrutinizer05 | yep | 17:12 |
DocScrutinizer05 | also I just realized I did a decimal error, 2000/s is factor 10 too slow for ECI still | 17:13 |
DocScrutinizer05 | Pali: you looked into the ECI stuff I pstaed a few hours ago? | 17:16 |
DocScrutinizer05 | pasted | 17:16 |
DocScrutinizer05 | Pali: http://mg.pov.lt/maemo-irclog/latest.log.html#t2016-12-23T11:22:12 | 17:16 |
Pali | yes, I have seen it | 17:17 |
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? | 17:23 |
Pali | /sys/class/gpio/ already supports it | 17:25 |
Pali | via poll on sysfs | 17:25 |
DocScrutinizer05 | wow | 17:25 |
Pali | but that sound driver refuse to do it | 17:25 |
DocScrutinizer05 | wait, sorry? | 17:26 |
DocScrutinizer05 | you're not referring to eci0 now, do you? | 17:26 |
Pali | I mean that gpio 40 | 17:26 |
Pali | with # echo 40 > /sys/class/gpio/export | 17:26 |
DocScrutinizer05 | aka TVOUT_EN? | 17:26 |
Pali | yes | 17:26 |
DocScrutinizer05 | :nod: | 17:27 |
Pali | but that should work for any gpio number | 17:27 |
KotCzarny | some years ago i saw a project using vga card as a fm radio generator | 17:27 |
Pali | [13:57:36] <Pali> #define RX51_ECI_SWITCH_1_GPIO 178 | 17:27 |
Pali | [13:57:41] <Pali> #define RX51_ECI_SWITCH_2_GPIO 182 | 17:27 |
Pali | those gpios are also owned by sound driver | 17:28 |
DocScrutinizer05 | so not exactly trivial to add an IRQ handler listening to that GPIO178 aka eci0, right? | 17:29 |
Pali | looks like not | 17:30 |
Pali | maybe some debug interface could exist... | 17:30 |
DocScrutinizer05 | though actually on hw level IRQ is sort of unentangled and orthogonal to GPIO-IN/OUT | 17:30 |
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 | 17:31 |
DocScrutinizer05 | particularly for input | 17:32 |
Pali | some info is there: cat /sys/kernel/debug/gpio | 17:43 |
*** cyphase has quit IRC | 17:58 | |
*** cyphase has joined #maemo | 18:03 | |
DocScrutinizer05 | o.O !!! "gpio-61 (eci0 ) in hi irq-221 edge-both" | 18:08 |
DocScrutinizer05 | YES! URQ edge-both, exactly what we need | 18:08 |
DocScrutinizer05 | IRQ* | 18:08 |
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 | 18:11 |
DocScrutinizer05 | usually that "userland process" is called worker thread | 18:12 |
DocScrutinizer05 | and actually runs in kernel domain still | 18:12 |
*** cyphase has quit IRC | 18:14 | |
DocScrutinizer05 | UGH, should be a wakeup IRQ though# | 18:14 |
DocScrutinizer05 | irq-221 edge-both wakeup | 18:15 |
Pali | 2.6.28 kernel does not support poll() syscall for gpio :-( | 18:16 |
Pali | https://www.kernel.org/doc/Documentation/gpio/sysfs.txt | 18:17 |
Pali | this is upstream kernel | 18:17 |
Pali | search for /sys/class/gpio/gpioN/ | 18:17 |
Pali | this is probably enough for upstream kernel | 18:17 |
Pali | but not for maemo 2.6.28 | 18:17 |
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 | 18:17 |
*** cyphase has joined #maemo | 18:19 | |
DocScrutinizer05 | Pali: afaik kernel IRQ handlers should be chainable | 18:19 |
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? | 18:20 |
Pali | but kernel gpio library does not allow it | 18:20 |
DocScrutinizer05 | damn! | 18:21 |
DocScrutinizer05 | seems it creates a /dev/input device | 18:21 |
DocScrutinizer05 | Dec 23 16:05:53 IroN900 kernel: [ 4663.989837] headphone (GPIO 177) is now connected | 18:22 |
DocScrutinizer05 | Dec 23 16:05:54 IroN900 kernel: [ 4665.067871] input: headset button as /class/input/input6 | 18:22 |
DocScrutinizer05 | how 'realtime' could that get? | 18:23 |
DocScrutinizer05 | IroN900:/sys/devices/platform/nokia-av# Dec 23 16:05:48 IroN900 kernel: [ 4658.466400] headphone (GPIO 177) is now disconnected | 18:23 |
DocScrutinizer05 | Dec 23 16:05:48 IroN900 ke_recv[1548]: device_removed:2695: udi: /org/freedesktop/Hal/devices/computer_logicaldev_input_1 | 18:23 |
DocScrutinizer05 | Dec 23 16:05:49 IroN900 mce[830]: Error accessing /dev/input/event4 (condition: 16). Ignoring | 18:23 |
DocScrutinizer05 | Dec 23 16:05:49 IroN900 mce[830]: Error when reading from /dev/input/event4: No such device | 18:23 |
Pali | hm... that input file is created after inserting headphones... | 18:24 |
DocScrutinizer05 | IOW would events in /dev/input/event* have timestamps? | 18:24 |
Pali | I think input events have timestamps | 18:24 |
DocScrutinizer05 | then we're already done, no? :-D | 18:24 |
Pali | but that input device reports only one thing | 18:25 |
DocScrutinizer05 | unless that input device has "debouncing" or shit | 18:25 |
Pali | when headset button is pressed | 18:25 |
DocScrutinizer05 | ARRRRGH! | 18:25 |
Pali | and it reports after 1s | 18:25 |
Pali | useless for now... | 18:25 |
DocScrutinizer05 | double-ARRRRGH! | 18:25 |
Pali | see: https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c#L106 | 18:26 |
Pali | this is that code | 18:26 |
DocScrutinizer05 | I see, it *does* >>"debouncing" or shit<< | 18:27 |
Pali | maybe easier would be to patch nokia-av.c and recompile just nokia-av.ko | 18:28 |
Pali | what all is needed? | 18:29 |
Pali | would not be easier to implement everything in that nokia-av.ko driver? | 18:30 |
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* | 18:30 |
DocScrutinizer05 | yes, exactly what you said while I typed slowly | 18:30 |
DocScrutinizer05 | basically what we need is not much different to the debounce function there | 18:31 |
Pali | ok, after we decode it into bytes.. those bytes are then raw ECI protocol? | 18:31 |
DocScrutinizer05 | yes | 18:31 |
Pali | ok | 18:32 |
Pali | and switching micbias on/off is other direction? | 18:32 |
DocScrutinizer05 | yes | 18:32 |
Pali | hm... so it needs correct timing | 18:32 |
Pali | and is nokia-av.ko initializing ECI? or we need to implement it? | 18:33 |
Pali | I see that nokia-av.ko already is doing with micbias | 18:33 |
Pali | something... | 18:33 |
DocScrutinizer05 | correct timing only really relevant intra-byte TX | 18:34 |
DocScrutinizer05 | I'd think the ECI protocil high level is really userland lib thing | 18:35 |
DocScrutinizer05 | incl initialization | 18:35 |
DocScrutinizer05 | no idea how HARM is doing it (or if at all) | 18:36 |
DocScrutinizer05 | I *think* N9/HARM knows and speaks ECI | 18:36 |
DocScrutinizer05 | they use a hw "UART" in TPS65951 that is absolutely undocumented | 18:37 |
DocScrutinizer05 | TI prolly inplemented it into TPS65951 on nokia's special request | 18:38 |
DocScrutinizer05 | for N9 | 18:38 |
DocScrutinizer05 | now if only I hadn't killed my N9, I could test | 18:39 |
DocScrutinizer05 | waaait, I should also be able to test it on N950, no? | 18:39 |
Pali | maybe yes | 18:39 |
Pali | I think easy solution would be to add support for poll() syscall on /sys/devices/platform/nokia-av/eci0 | 18:42 |
Pali | and /sys/devices/platform/nokia-av/eci1 | 18:42 |
Pali | which are needed? both of them? | 18:43 |
DocScrutinizer05 | Oh Nokia F U!! N950 is AHJ | 18:43 |
DocScrutinizer05 | eci0 is needed | 18:44 |
Pali | eci1 too? | 18:44 |
DocScrutinizer05 | it doesn't even detect the headset when I plug it in | 18:45 |
DocScrutinizer05 | no | 18:45 |
DocScrutinizer05 | eci1 is for detection only | 18:45 |
DocScrutinizer05 | not related to ECI protocol | 18:46 |
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) | 18:46 |
DocScrutinizer05 | eci1 goes 0 whenever a jack with a mic impedance < ~8k Ohm gets plugged in | 18:47 |
DocScrutinizer05 | oops < 15k | 18:48 |
DocScrutinizer05 | http://wstaw.org/m/2016/12/23/plasma-desktopm17764.png 22k/(22k+6k8)=X/(X+4k7) | 18:50 |
DocScrutinizer05 | aka X=22k * (4k7/6k8) | 18:51 |
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 | 18:52 |
DocScrutinizer05 | so a mere detector thing for detection phase after plugin | 18:52 |
DocScrutinizer05 | though of arguable value, given we also have madc | 18:53 |
DocScrutinizer05 | anyway not needed for ECI protocol | 18:54 |
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... | 18:56 |
KotCzarny | x220 is a few gens higher | 18:56 |
KotCzarny | it would be like you were looking for t520 ;) | 18:57 |
Vajb | interesting that they r about the same price then | 18:58 |
KotCzarny | smaller is more expensive | 18:58 |
KotCzarny | usually | 18:59 |
Vajb | x220 is smaller? | 18:59 |
KotCzarny | x series is ultraportable | 18:59 |
KotCzarny | t series is normal work machines | 18:59 |
Vajb | t520 330e | 18:59 |
KotCzarny | forget 330e | 19:00 |
KotCzarny | hehe | 19:00 |
KotCzarny | unless they b0rk the series numbers, but afair it was like that always | 19:00 |
KotCzarny | ie t60/x60, t500/x200 | 19:00 |
KotCzarny | i got mine cheap when some company was upgrading from t500 laptops to t540 | 19:01 |
Vajb | yes. Im going to check one store which used to sell their old business laptops | 19:02 |
Vajb | last time i visite there were some lenovo machines around 150e. Can't recall the number tho | 19:03 |
Vajb | visited* | 19:03 |
KotCzarny | i bught direct via local classifieds site, 2nd hand stores usually add their markup | 19:03 |
Vajb | e series is low end i suppose? | 19:03 |
KotCzarny | yup, you only want t or x | 19:04 |
KotCzarny | depending if you want screen size or mobility | 19:04 |
KotCzarny | i dont remember if newer x series accomodated for dvd slot | 19:04 |
KotCzarny | but having it you can swap it for 2nd hdd, which is much more useful | 19:04 |
KotCzarny | in that case you want t series (or a dock) | 19:05 |
Vajb | i saw docks for sale for 30e | 19:05 |
KotCzarny | first get a machine | 19:05 |
Vajb | sure | 19:06 |
Vajb | i suppose they come with win7 at least... | 19:06 |
Vajb | i've had it with vista | 19:06 |
KotCzarny | depends, some with vista, some with win7 | 19:06 |
KotCzarny | it was a switching period | 19:07 |
Vajb | i c | 19:07 |
Vajb | and well vista eol will be next year anyway | 19:08 |
KotCzarny | you can grab win7_64 boxed version, then install whenever you like | 19:09 |
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 :-/ | 19:09 |
DocScrutinizer05 | still I don't get it why it doesn't work | 19:11 |
Vajb | oh t series is 64bit? | 19:11 |
KotCzarny | most core2duos are | 19:11 |
KotCzarny | if not all ;) | 19:11 |
Vajb | i c | 19:11 |
KotCzarny | and you can always change the cpu | 19:12 |
KotCzarny | as its socketed (soldered in x) | 19:12 |
KotCzarny | you should write all those requirements on your check-list | 19:13 |
Vajb | i don't have much requirements :) | 19:13 |
Vajb | i just have to be cheap and snappy | 19:13 |
Vajb | it* | 19:14 |
KotCzarny | add ssd to the list | 19:14 |
Vajb | oh yes that will kill the cheap bit | 19:14 |
KotCzarny | ssd drives are reusable | 19:14 |
KotCzarny | you can always move it from/to | 19:14 |
Vajb | ok i'll make some notes so t or x serie ssd | 19:15 |
KotCzarny | you can get it with hdd and just buy ssd yourself (then move hdd to the bay) | 19:15 |
Vajb | r they all core2duo because i think i saw some sold as i5? | 19:15 |
KotCzarny | t500 are from core2duo era, i think t510 or t520 was the first ones with intel iX | 19:16 |
KotCzarny | http://www.thinkwiki.org/wiki/Category:T_Series | 19:16 |
KotCzarny | yeah, all t500 are core2duo | 19:16 |
KotCzarny | t510 are i5/i7 | 19:17 |
Vajb | ah i think they were some others then | 19:17 |
Vajb | ok | 19:17 |
KotCzarny | well, t4xx series are similar to t5xx, but using smaller screen | 19:18 |
KotCzarny | so you might hunt those too | 19:18 |
KotCzarny | (14" vs 15") | 19:18 |
Vajb | ok, no versions with 17"? | 19:19 |
KotCzarny | not in the normal thinkpad series | 19:20 |
Vajb | ok i think i'll go with t series because my laptop just sits on the table always | 19:20 |
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 | 19:22 |
*** louisdk has joined #maemo | 19:23 | |
KotCzarny | or just be patient and look for it in the nearest 6 months | 19:23 |
*** louis__ has joined #maemo | 19:23 | |
KotCzarny | acer still works, so no rush | 19:23 |
Vajb | yup, thx bbl | 19:23 |
KotCzarny | and you can put 10e/month into 'new laptop fund of vajb' | 19:23 |
Vajb | hehe yeah | 19:24 |
Vajb | and acer works but vista not so much | 19:24 |
KotCzarny | go xp? | 19:24 |
*** ced117_ has quit IRC | 19:25 | |
*** zGrr has quit IRC | 19:44 | |
KotCzarny | http://www.cnx-software.com/2016/12/23/25-nanopi-a64-is-a-compact-yet-features-packed-allwinner-a64-development-board/ | 19:56 |
KotCzarny | um, wrong chan | 19:56 |
*** cyphase has quit IRC | 19:58 | |
*** cyphase has joined #maemo | 20:04 | |
*** spinal84 has joined #maemo | 20:07 | |
*** pagurus has joined #maemo | 20:11 | |
*** pagurus has quit IRC | 20:18 | |
Vajb | is xp still supported? | 20:19 |
KotCzarny | i think there was some hack | 20:20 |
Vajb | i'll see if i can find vista disk and try repair | 20:21 |
Vajb | sfc found some weird registry issues | 20:22 |
KotCzarny | viree? | 20:22 |
Vajb | umm come again? | 20:27 |
KotCzarny | virus? | 20:27 |
Vajb | shouldn't be | 20:27 |
Vajb | i've used trendmicro house call + ms antivirus also two scanners for rootkits and three for malware | 20:28 |
KotCzarny | vista + 2 av programs? no wonder its slow as molasses | 20:29 |
Vajb | trendmicro is just online scanner which i use occasionally to get second opinion | 20:30 |
sicelo- | what are you using xp for? | 20:30 |
Vajb | sicelo-: it was just suggestion to replace vista | 20:31 |
Vajb | i have vista which refuses to update itself | 20:31 |
sicelo- | xp won't update at all :) | 20:31 |
KotCzarny | btw. that windows update fail also happens on w7 | 20:31 |
Vajb | so problem solved :p | 20:31 |
KotCzarny | it's m$ fault | 20:31 |
Vajb | KotCzarny: yes i know, but there is a tool to fix it from ms. Sadly it is not working under vista | 20:32 |
Vajb | speaking of "forcing users to switch" | 20:33 |
KotCzarny | i've had w7 systems stuck on 'checking for updates' no matter what i've tried | 20:33 |
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 | 20:33 |
KotCzarny | yup, there is a tool for w7 too. didnt work often | 20:34 |
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 :-/ | 20:34 |
Vajb | i like cmd apt-get i can see what is happening that good looking knight rider rip off doesn't tell much | 20:35 |
KotCzarny | sicelo: use lxde? or even fluxbox? or mate? | 20:35 |
KotCzarny | no need to reinstall, just switch DE | 20:35 |
sicelo- | lxde vs. xfce .. whis is usually bette? | 20:35 |
KotCzarny | you definitely want something light | 20:35 |
KotCzarny | both are fine | 20:35 |
KotCzarny | so up to your liking | 20:36 |
sicelo- | reinstall because i want to see if i 'solve' the hibernation issue | 20:36 |
sicelo- | tbh both Gnome and KDE have been fine performance-wise on the X40 :) | 20:36 |
Vajb | i think i've used both. Crunchbang has xfce i think | 20:36 |
sicelo- | will look at fluxbox a bit more | 20:36 |
Vajb | both r too bloated for my system | 20:37 |
Vajb | i like the feature that i can get to menu from anywhere on background | 20:38 |
sicelo- | specs? | 20:38 |
Vajb | 1,3ghz amd tb | 20:38 |
Vajb | around 700mb of ram | 20:38 |
Vajb | some geforce 5x series agb display card | 20:39 |
KotCzarny | try fluxbox | 20:39 |
sicelo- | mine is 1.4GHz, 1GB RAM, on-board graphics. i find gnome/kde perfectly useable. anyway, i am happy with N900 performance, so ... :) | 20:40 |
Vajb | it is kind of sad that cpu power nowadays is "limitless" | 20:40 |
*** L29Ah has quit IRC | 20:40 | |
KotCzarny | its not ;) | 20:40 |
Vajb | no one bothers to optimize | 20:40 |
Vajb | especially web pages | 20:41 |
Vajb | my puter used to be fine in flash6 time | 20:41 |
Vajb | i could browse anything and watch the videos | 20:41 |
KotCzarny | i had 1ghz tb too | 20:41 |
KotCzarny | still have that cpu in the closet probably | 20:41 |
*** cyphase has quit IRC | 20:42 | |
Vajb | take it in use | 20:43 |
Vajb | play with puppy linux | 20:43 |
KotCzarny | i can send it to you if you want | 20:43 |
KotCzarny | :) | 20:43 |
Vajb | i got laptop which had busted hdd so i installed puppy into usb memory and it was lightning fast | 20:43 |
KotCzarny | for me it's only thinkpads + my gaming rig | 20:44 |
KotCzarny | and remember, i have and use and love my x40 | 20:44 |
KotCzarny | pentium-m single core @1.2ghz, 1.5gb ram | 20:44 |
Vajb | yet another lenovo? | 20:44 |
KotCzarny | only thing that makes it fly is hdd | 20:44 |
KotCzarny | ssd i mean | 20:44 |
sicelo- | same here | 20:44 |
KotCzarny | nope. original ibm :P | 20:44 |
Vajb | oh i see | 20:45 |
sunshavi | KotCzarny: You have more power than my compaq evo n600c | 20:45 |
sicelo- | i would love to up the RAM to 1.5GB as well. currently have 1GB | 20:45 |
Vajb | pentium m? Mobile? That low end processor serie? | 20:45 |
sicelo- | Vajb: http://www.thinkwiki.org/wiki/Category:X40 | 20:45 |
Vajb | i'd love to have some 512mb sdram | 20:46 |
Vajb | was there ever 1024mb? | 20:46 |
KotCzarny | yup | 20:46 |
KotCzarny | base(soldered) 512megs, and 1gb module | 20:46 |
Vajb | oh so basically i could have 3gigs of memory 0.0 | 20:46 |
*** cyphase has joined #maemo | 20:47 | |
sicelo- | i'm used to debian now (blame N900) ... what other distro could i try (not Ubuntu/Mint) ... | 20:47 |
Vajb | mb has 3 slots | 20:47 |
KotCzarny | sicelo: devuan? | 20:47 |
KotCzarny | if you like cmdline/scripts and doing most things by hand slackware | 20:47 |
Vajb | sicelo-: try crunchbang follower | 20:47 |
Vajb | can't remember the name | 20:47 |
KotCzarny | if you like things compiled for your setup, gentoo | 20:47 |
sicelo- | compiling on X40 .. sounds like fun :) | 20:48 |
KotCzarny | ever heard of distcc? ;) | 20:48 |
sicelo- | never looked at it in detail | 20:48 |
KotCzarny | essentially you need same gcc/g++ on other machine and network | 20:49 |
KotCzarny | and its like your compiling capabilities multiplied. but in case of x40 (single core) preprocessing takes most of the time | 20:49 |
KotCzarny | hmm, i might've lied about 1gb sdram (forgot x40 uses ddr1) | 20:51 |
Vajb | well actually i meant sdram sticks to my desktop ;) | 20:53 |
KotCzarny | yeah, that's what i meant | 20:53 |
KotCzarny | thought x40 uses sdram (and i have 1gb stick in it) | 20:53 |
Vajb | ah i see | 20:53 |
Vajb | i thin i have 256+256+128 | 20:54 |
KotCzarny | check if you can get x40/x60/x61 cheap enough | 20:54 |
Vajb | think too | 20:54 |
sicelo- | verdict about Arch? | 20:56 |
sunshavi | sicelo: i am an arch user | 20:57 |
Vajb | tried once long time ago didn't instantly fell in love | 20:57 |
sunshavi | nice for me, but when ready i am going to move to bsd for avoiding the systemd issue | 20:57 |
sunshavi | I have more than 10 years using it. | 20:57 |
sunshavi | But distro is not important when using emacs. Distro is just a boot loader | 20:58 |
Vajb | care to buy vowel? BSOD | 20:59 |
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**!!!<< | 20:59 |
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) | 21:00 |
* DocScrutinizer05 suggests swapping sleeve and center pin for RCA/Cinch jacks too, just "necause we can" | 21:00 | |
sicelo- | wonder if i shouldn't try slackware instead for now :-/ | 21:01 |
sunshavi | nice thing about arch is pkgs are always up to date. so probably my way is going to be pacbsd | 21:01 |
KotCzarny | sicelo, you dont have to reinstall, with linux you can have multiple systems on one drive | 21:09 |
sicelo- | i don't have large HDD though | 21:12 |
KotCzarny | 8gb per os should be fine these days, unless specifically finetuned | 21:13 |
*** florian has joined #maemo | 21:37 | |
*** louisdk has quit IRC | 21:51 | |
*** louis__ has quit IRC | 21:51 | |
*** cyphase has quit IRC | 22:03 | |
*** cyphase has joined #maemo | 22:08 | |
*** Oksanaa has joined #maemo | 22:10 | |
Oksanaa | Anybody got mscim to work? I installed mscimswitcher, mscim-hangul, mscim-tables-ja, and all I got is "mscim=no virtual keyboard" | 22:12 |
*** Oksanaa has left #maemo | 22:14 | |
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. | 23:00 |
sicelo- | weird | 23:00 |
*** CraigEr has quit IRC | 23:03 | |
*** CraigEr has joined #maemo | 23:03 | |
*** pkill9 has quit IRC | 23:13 | |
*** me has joined #maemo | 23:54 | |
*** me is now known as Guest80759 | 23:55 | |
*** Guest80759 is now known as pkill9 | 23:55 | |
*** pkill9 has quit IRC | 23:58 | |
*** me has joined #maemo | 23:58 | |
*** me is now known as Guest39466 | 23:58 | |
*** Guest39466 is now known as pkill9 | 23:58 | |
*** cyphase has quit IRC | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!