| *** cyphase has joined #maemo | 00:03 | |
| *** XDS2010 has quit IRC | 00:23 | |
| *** XDS2010 has joined #maemo | 00:26 | |
| Pali | DocScrutinizer05: https://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power;a=commit;h=0533144967fcf0cc4e485cf40e586140e7a1d960 | 01:03 |
|---|---|---|
| Pali | we already have this patch in kp53 | 01:03 |
| Pali | which via that input device report *immediately* state of eci0 gpio when changed | 01:03 |
| Pali | https://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power;a=blob;f=kernel-power-2.6.28/debian/patches/nokia-av_key.patch | 01:03 |
| Pali | it is called at begining of that irq handler for eci0 | 01:04 |
| Pali | so via poll() on that /dev/input/ device (created after plugging headset; disappear after unplugging) you can wait for events | 01:07 |
| *** geaaru_ has joined #maemo | 01:09 | |
| Pali | and /dev/input device events contains timestamp! | 01:10 |
| Pali | struct input_event { struct timeval time; __u16 type; __u16 code; __s32 value; } | 01:10 |
| Pali | this is structure which send | 01:11 |
| *** geaaru has quit IRC | 01:12 | |
| Pali | type is EV_KEY (0x01); code is KEY_PROG1 (148); value is boolean negation of eci0 gpio state | 01:12 |
| Pali | if input subsystem is fast enough we do not need any kernel patching! | 01:13 |
| DocScrutinizer05 | yes! great :-)) | 01:13 |
| DocScrutinizer05 | actually only needs to be "fast enough" to get timestamp and handle forward it before next IRQ after 80us comes in | 01:15 |
| Pali | do you need to process eci0 realtime, or is "buffered" enough with correct timestamp? | 01:16 |
| Pali | e.g. if you get ten events at once, but with timestamp | 01:17 |
| DocScrutinizer05 | the process which soes "poll() on that /dev/input/ device" probbaly needs realtime scheduling prio, and stay active (not allow scheduler to do task switching) until no more inbound events from poll for a 20ms | 01:18 |
| DocScrutinizer05 | even 32 or 40 events with timestamp are fine when just buffered | 01:18 |
| *** geaaru_ has quit IRC | 01:19 | |
| Pali | this needs experiment if input layer is enough or not | 01:19 |
| DocScrutinizer05 | it seems no reply sent by headset is longer a burst than 2 bytes | 01:19 |
| DocScrutinizer05 | after the 16 (18 incl startbits) bits are sent, the userland process can analyue the buffered events and has "all the time of this world" to do so | 01:20 |
| DocScrutinizer05 | 18 bits = 36 events | 01:21 |
| DocScrutinizer05 | analyze* | 01:22 |
| DocScrutinizer05 | 36 events -> 2 bytes ==>/dev/eci or dbus-signal or whatever | 01:23 |
| DocScrutinizer05 | communication layer then sends a respomse, if needed. Or next command if needed. Or simply makes sure the event queue is empty and everything ready to receive next event | 01:24 |
| DocScrutinizer05 | time until respinse or next command isn't critical aiui, it may take several dizen milliseconds | 01:25 |
| DocScrutinizer05 | God! | 01:25 |
| DocScrutinizer05 | time until response or next command isn't critical aiui, it may take several dozen milliseconds | 01:25 |
| DocScrutinizer05 | afaik (so far), Device sends 4ms low pulse to start session, on plug-in. Headset responds with a single startbit. D sends IDENTIFY command (0xf0a5 or whatever). H responds with some 2 byte(?) answer. D prolly sends read-memory commands like read(1) read(2) aso. H resp content of byte 1, byte 2 etc of config storage. eventually session established and HS initialized. Now when user presses a key on HS, it sends 2byte info and Device sends | 01:31 |
| DocScrutinizer05 | ACK a few ms later | 01:31 |
| Pali | and must device start session immediately after plug-in? or can be it e.g. 10sec after plug-in? | 01:33 |
| Pali | because it takes some time after udev create /dev/input device after plug-in | 01:33 |
| *** erstazi_ has joined #maemo | 01:37 | |
| DocScrutinizer05 | I think the session gets started by 4ms of low pulse | 01:37 |
| DocScrutinizer05 | at any time | 01:37 |
| Pali | and session is started by device? or by headset? | 01:37 |
| DocScrutinizer05 | by device | 01:38 |
| *** erstazi has quit IRC | 01:38 | |
| *** erstazi_ is now known as erstazi | 01:38 | |
| Pali | ok, then slow udev and creating input device should not be a problem | 01:38 |
| DocScrutinizer05 | http://neo900.org/stuff/joerg/ECI/init/ | 01:38 |
| DocScrutinizer05 | http://neo900.org/stuff/joerg/ECI/init/ECI_init01_ph4ms_low_hsA2pulses.jpg | 01:39 |
| DocScrutinizer05 | og, HS answers with TWO startbit | 01:39 |
| DocScrutinizer05 | oh* | 01:39 |
| DocScrutinizer05 | note how the HS pulses have a lower low voltage (hard to see but it's there) | 01:41 |
| DocScrutinizer05 | and HS pulses also have that tiny bright line at beginning of falling edge | 01:41 |
| DocScrutinizer05 | in http://neo900.org/stuff/joerg/ECI/init/ECI_init01_ph4ms_low_hsA2pulses.jpg you see 4ms wide start pulse by Device, then 2 startbit pulses by HS, then on right side you see the Device sending IDENTIFY command | 01:43 |
| DocScrutinizer05 | after 4.x ms | 01:43 |
| DocScrutinizer05 | I'm sure those 4.x ms are not critical | 01:43 |
| DocScrutinizer05 | http://neo900.org/stuff/joerg/ECI/init/ECI_init02_phCMD_identify.jpg is the IDENTIFY command shifted into screen from right | 01:44 |
| DocScrutinizer05 | HS replies by http://neo900.org/stuff/joerg/ECI/init/ECI_init03_hsANSWER_ident.jpg | 01:46 |
| Pali | anyway, how is that defaul n900 headset with button working? | 01:46 |
| Pali | it is ECI? or different protocol? | 01:46 |
| DocScrutinizer05 | and sorry I was wrong, those seem to be 4 byte | 01:46 |
| DocScrutinizer05 | default has no damn clue about boolean logic, it siply shirts MICBIAs to GND as long as you press the button | 01:47 |
| DocScrutinizer05 | simply shorts* | 01:47 |
| DocScrutinizer05 | so basically it sends a veeeeeery long "ECI oulse" | 01:48 |
| DocScrutinizer05 | pulse. sorry can't type anymore | 01:48 |
| DocScrutinizer05 | re high level protocol, I guess you can find all the gory details in the existing sourcecode | 01:51 |
| DocScrutinizer05 | https://lwn.net/Articles/420775/ etc | 01:52 |
| DocScrutinizer05 | as I already mentioned, my code reading of that stuff resulted in thinking that it uses whatever MCU to do the bytes -> raw pulses and back to bytes | 01:55 |
| DocScrutinizer05 | iirc they even support TWO different MCU but have no info for either of them. So we need to emulate what the MCU does: convert byte commands to pulse bursts and bitbbang those out. And receive inbound bursts and convert them to bytes | 01:56 |
| DocScrutinizer05 | what a MCU can do, we do hands down on OMAP, without sweating our shirt ;-) | 02:00 |
| DocScrutinizer05 | I think they send the command bytes to MCU via I2C (sorry it's at least a year since I read that source): http://mailman.alsa-project.org/pipermail/alsa-devel/2011-February/036377.html | 02:06 |
| DocScrutinizer05 | we would send them to a bitbanging kernel driver instead | 02:07 |
| DocScrutinizer05 | and instead of reading inbound bytes from I2C we would analyze the event queue to generate those data bytes | 02:08 |
| *** Pali has quit IRC | 02:10 | |
| DocScrutinizer05 | or maybe s/ bitbanging kernel driver / a RT-prio userland program sending precisely timed toggle instructions for one burst to the ALSA_whatever interface to TVOUT_EN / | 02:11 |
| *** Kabouik_ has joined #maemo | 02:30 | |
| *** Konsieur has quit IRC | 02:33 | |
| *** florian has quit IRC | 02:43 | |
| *** Kabouik_ has quit IRC | 02:59 | |
| *** Kabouik_ has joined #maemo | 03:01 | |
| *** lxp has joined #maemo | 06:01 | |
| *** lxp1 has quit IRC | 06:03 | |
| *** Kabouik_ has quit IRC | 06:12 | |
| *** Kabouik_ has joined #maemo | 06:12 | |
| *** jon_y has quit IRC | 07:04 | |
| *** jon_y has joined #maemo | 07:06 | |
| *** lobito has quit IRC | 07:08 | |
| *** DocScrutinizer05 has quit IRC | 07:33 | |
| *** DocScrutinizer05 has joined #maemo | 07:33 | |
| *** hurrian_ has joined #maemo | 07:48 | |
| *** hurrian has quit IRC | 07:48 | |
| *** clopez has quit IRC | 09:58 | |
| *** spinal84 has quit IRC | 10:01 | |
| *** clopez has joined #maemo | 10:03 | |
| *** louis__ has joined #maemo | 10:11 | |
| *** louisdk has joined #maemo | 10:11 | |
| *** Pali has joined #maemo | 10:32 | |
| *** shentey has joined #maemo | 11:00 | |
| *** krnlyng has quit IRC | 11:19 | |
| *** shentey has quit IRC | 11:20 | |
| *** florian has joined #maemo | 11:28 | |
| *** krnlyng has joined #maemo | 11:32 | |
| *** florian has quit IRC | 11:33 | |
| *** florian has joined #maemo | 13:16 | |
| *** hurrian has joined #maemo | 13:48 | |
| *** hurrian_ has quit IRC | 13:50 | |
| *** silviof has quit IRC | 13:51 | |
| *** silviof has joined #maemo | 14:08 | |
| *** Kabouik_ has quit IRC | 14:59 | |
| *** Pali has quit IRC | 16:27 | |
| *** Pali has joined #maemo | 16:28 | |
| *** jon_y has quit IRC | 16:34 | |
| *** jon_y has joined #maemo | 16:35 | |
| *** M4rtinK has joined #maemo | 17:28 | |
| *** florian has quit IRC | 17:37 | |
| *** Wizzup has quit IRC | 18:58 | |
| *** krnlyng has quit IRC | 18:59 | |
| *** krnlyng has joined #maemo | 19:03 | |
| *** Wizzup has joined #maemo | 19:06 | |
| *** Mr_Pingu has quit IRC | 19:44 | |
| *** spinal84 has joined #maemo | 19:54 | |
| *** florian has joined #maemo | 20:18 | |
| *** Kabouik has joined #maemo | 20:22 | |
| *** ced117_ has joined #maemo | 20:28 | |
| *** Mr_Pingu has joined #maemo | 20:40 | |
| sicelo- | KotCzarny: what kernel you run on your X40? | 20:51 |
| sicelo- | my hibernate problem does not exist on kernel 3.16, but 4.8 consistently fails | 20:51 |
| KotCzarny | sicelo: to be honest, hibernate stopped working for me long time ago with tuxonine, i just run it 24/7 nowadays | 20:52 |
| sicelo- | :) | 20:52 |
| sicelo- | at least i have a workaround .. but i'd like to find out where the problem comes from | 20:53 |
| *** at1as has joined #maemo | 20:53 | |
| KotCzarny | probably graphics drivers | 20:53 |
| KotCzarny | it was always graphics | 20:53 |
| KotCzarny | disable x and check if it works there | 20:53 |
| ceene | ahyckaCollins says merry christmas too | 20:54 |
| ceene | i need to renick her | 20:54 |
| KotCzarny | cheers! | 20:54 |
| sicelo- | it was failing even when i have init=/bin/sh ... without x | 20:55 |
| KotCzarny | you might try older toi branches | 20:55 |
| KotCzarny | or you might try making default linux swsusp | 20:56 |
| sicelo- | btw, i decided to try LxQT .. working good so far | 20:57 |
| KotCzarny | i'm suspecting some specific .config options, but never tried to pinpoint which ones made hibernate to fail | 21:00 |
| *** at1as has quit IRC | 21:20 | |
| *** erstazi has quit IRC | 21:22 | |
| *** AndrewX192 has quit IRC | 22:03 | |
| *** erstazi has joined #maemo | 22:09 | |
| Vajb | merry xmass or happy holidays maemo ppl | 22:25 |
| KotCzarny | mass mass | 22:26 |
| Vajb | right e=mc2 | 22:26 |
| KotCzarny | solving x for mass | 22:36 |
| *** Kabouik has quit IRC | 22:43 | |
| *** Kabouik has joined #maemo | 22:44 | |
| Vajb | i thought it was just multiplier there | 22:48 |
| *** AndrewX192 has joined #maemo | 23:02 | |
| sunshavi | +1 to Vajb Xmas msg, people | 23:15 |
| KotCzarny | so, allwinner is mostly arm+dw ? | 23:19 |
| KotCzarny | erm. wrong chan | 23:19 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!
