IRC log of #maemo for Saturday, 2016-12-24

*** cyphase has joined #maemo00:03
*** XDS2010 has quit IRC00:23
*** XDS2010 has joined #maemo00:26
PaliDocScrutinizer05: https://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power;a=commit;h=0533144967fcf0cc4e485cf40e586140e7a1d96001:03
Paliwe already have this patch in kp5301:03
Paliwhich via that input device report *immediately* state of eci0 gpio when changed01:03
Palihttps://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power;a=blob;f=kernel-power-2.6.28/debian/patches/nokia-av_key.patch01:03
Paliit is called at begining of that irq handler for eci001:04
Paliso via poll() on that /dev/input/ device (created after plugging headset; disappear after unplugging) you can wait for events01:07
*** geaaru_ has joined #maemo01:09
Paliand /dev/input device events contains timestamp!01:10
Palistruct input_event { struct timeval time; __u16 type; __u16 code; __s32 value; }01:10
Palithis is structure which send01:11
*** geaaru has quit IRC01:12
Palitype is EV_KEY (0x01); code is KEY_PROG1 (148); value is boolean negation of eci0 gpio state01:12
Paliif input subsystem is fast enough we do not need any kernel patching!01:13
DocScrutinizer05yes! great :-))01:13
DocScrutinizer05actually only needs to be "fast enough" to get timestamp and handle forward it before next IRQ after 80us comes in01:15
Palido you need to process eci0 realtime, or is "buffered" enough with correct timestamp?01:16
Palie.g. if you get ten events at once, but with timestamp01:17
DocScrutinizer05the 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 20ms01:18
DocScrutinizer05even 32 or 40 events with timestamp are fine when just buffered01:18
*** geaaru_ has quit IRC01:19
Palithis needs experiment if input layer is enough or not01:19
DocScrutinizer05it seems no reply sent by headset is longer a burst than 2 bytes01:19
DocScrutinizer05after 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 so01:20
DocScrutinizer0518 bits = 36 events01:21
DocScrutinizer05analyze*01:22
DocScrutinizer0536 events -> 2 bytes ==>/dev/eci or dbus-signal or whatever01:23
DocScrutinizer05communication 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 event01:24
DocScrutinizer05time until respinse or next command isn't critical aiui, it may take several dizen milliseconds01:25
DocScrutinizer05God!01:25
DocScrutinizer05time until response or next command isn't critical aiui, it may take several dozen milliseconds01:25
DocScrutinizer05afaik (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 sends01:31
DocScrutinizer05ACK a few ms later01:31
Paliand must device start session immediately after plug-in? or can be it e.g. 10sec after plug-in?01:33
Palibecause it takes some time after udev create /dev/input device after plug-in01:33
*** erstazi_ has joined #maemo01:37
DocScrutinizer05I think the session gets started by 4ms of low pulse01:37
DocScrutinizer05at any time01:37
Paliand session is started by device? or by headset?01:37
DocScrutinizer05by device01:38
*** erstazi has quit IRC01:38
*** erstazi_ is now known as erstazi01:38
Paliok, then slow udev and creating input device should not be a problem01:38
DocScrutinizer05http://neo900.org/stuff/joerg/ECI/init/01:38
DocScrutinizer05http://neo900.org/stuff/joerg/ECI/init/ECI_init01_ph4ms_low_hsA2pulses.jpg01:39
DocScrutinizer05og, HS answers with TWO startbit01:39
DocScrutinizer05oh*01:39
DocScrutinizer05note how the HS pulses have a lower low voltage (hard to see but it's there)01:41
DocScrutinizer05and HS pulses also have that tiny bright line at beginning of falling edge01:41
DocScrutinizer05in 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 command01:43
DocScrutinizer05after 4.x ms01:43
DocScrutinizer05I'm sure those 4.x ms are not critical01:43
DocScrutinizer05http://neo900.org/stuff/joerg/ECI/init/ECI_init02_phCMD_identify.jpg is the IDENTIFY command shifted into screen from right01:44
DocScrutinizer05HS replies by http://neo900.org/stuff/joerg/ECI/init/ECI_init03_hsANSWER_ident.jpg01:46
Palianyway, how is that defaul n900 headset with button working?01:46
Paliit is ECI? or different protocol?01:46
DocScrutinizer05and sorry I was wrong, those seem to be 4 byte01:46
DocScrutinizer05default has no damn clue about boolean logic, it siply shirts MICBIAs to GND as long as you press the button01:47
DocScrutinizer05simply shorts*01:47
DocScrutinizer05so basically it sends a veeeeeery long "ECI oulse"01:48
DocScrutinizer05pulse. sorry can't type anymore01:48
DocScrutinizer05re high level protocol, I guess you can find all the gory details in the existing sourcecode01:51
DocScrutinizer05https://lwn.net/Articles/420775/ etc01:52
DocScrutinizer05as 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 bytes01:55
DocScrutinizer05iirc 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 bytes01:56
DocScrutinizer05what a MCU can do, we do hands down on OMAP, without sweating our shirt ;-)02:00
DocScrutinizer05I 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.html02:06
DocScrutinizer05we would send them to a bitbanging kernel driver instead02:07
DocScrutinizer05and instead of reading inbound bytes from I2C we would analyze the event queue to generate those data bytes02:08
*** Pali has quit IRC02:10
DocScrutinizer05or 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 #maemo02:30
*** Konsieur has quit IRC02:33
*** florian has quit IRC02:43
*** Kabouik_ has quit IRC02:59
*** Kabouik_ has joined #maemo03:01
*** lxp has joined #maemo06:01
*** lxp1 has quit IRC06:03
*** Kabouik_ has quit IRC06:12
*** Kabouik_ has joined #maemo06:12
*** jon_y has quit IRC07:04
*** jon_y has joined #maemo07:06
*** lobito has quit IRC07:08
*** DocScrutinizer05 has quit IRC07:33
*** DocScrutinizer05 has joined #maemo07:33
*** hurrian_ has joined #maemo07:48
*** hurrian has quit IRC07:48
*** clopez has quit IRC09:58
*** spinal84 has quit IRC10:01
*** clopez has joined #maemo10:03
*** louis__ has joined #maemo10:11
*** louisdk has joined #maemo10:11
*** Pali has joined #maemo10:32
*** shentey has joined #maemo11:00
*** krnlyng has quit IRC11:19
*** shentey has quit IRC11:20
*** florian has joined #maemo11:28
*** krnlyng has joined #maemo11:32
*** florian has quit IRC11:33
*** florian has joined #maemo13:16
*** hurrian has joined #maemo13:48
*** hurrian_ has quit IRC13:50
*** silviof has quit IRC13:51
*** silviof has joined #maemo14:08
*** Kabouik_ has quit IRC14:59
*** Pali has quit IRC16:27
*** Pali has joined #maemo16:28
*** jon_y has quit IRC16:34
*** jon_y has joined #maemo16:35
*** M4rtinK has joined #maemo17:28
*** florian has quit IRC17:37
*** Wizzup has quit IRC18:58
*** krnlyng has quit IRC18:59
*** krnlyng has joined #maemo19:03
*** Wizzup has joined #maemo19:06
*** Mr_Pingu has quit IRC19:44
*** spinal84 has joined #maemo19:54
*** florian has joined #maemo20:18
*** Kabouik has joined #maemo20:22
*** ced117_ has joined #maemo20:28
*** Mr_Pingu has joined #maemo20: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 fails20:51
KotCzarnysicelo: to be honest, hibernate stopped working for me long time ago with tuxonine, i just run it 24/7 nowadays20:52
sicelo-:)20:52
sicelo-at least i have a workaround .. but i'd like to find out where the problem comes from20:53
*** at1as has joined #maemo20:53
KotCzarnyprobably graphics drivers20:53
KotCzarnyit was always graphics20:53
KotCzarnydisable x and check if it works there20:53
ceeneahyckaCollins says merry christmas too20:54
ceenei need to renick her20:54
KotCzarnycheers!20:54
sicelo-it was failing even when i have init=/bin/sh ... without x20:55
KotCzarnyyou might try older toi branches20:55
KotCzarnyor you might try making default linux swsusp20:56
sicelo-btw, i decided to try LxQT .. working good so far20:57
KotCzarnyi'm suspecting some specific .config options, but never tried to pinpoint which ones made hibernate to fail21:00
*** at1as has quit IRC21:20
*** erstazi has quit IRC21:22
*** AndrewX192 has quit IRC22:03
*** erstazi has joined #maemo22:09
Vajbmerry xmass or happy holidays maemo ppl22:25
KotCzarnymass mass22:26
Vajbright e=mc222:26
KotCzarnysolving x for mass22:36
*** Kabouik has quit IRC22:43
*** Kabouik has joined #maemo22:44
Vajbi thought it was just multiplier there22:48
*** AndrewX192 has joined #maemo23:02
sunshavi+1 to Vajb Xmas msg, people23:15
KotCzarnyso, allwinner is mostly arm+dw ?23:19
KotCzarnyerm. wrong chan23:19

Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!