--- Log for 10.06.124 Server: tantalum.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 14 days and 7 hours ago 00.34.44 # <_bilgus_> so you are saying that line out detects the plug into the extension cord but not the removal whereas the headphone one only detects the plug into the port? 00.35.26 # <_bilgus_> I mean they could be checking the resistance / amperage etc 01.11.34 Quit Xeha (Ping timeout: 268 seconds) 01.15.07 Quit rasher (Read error: Connection reset by peer) 01.21.51 *** Saving seen data "./dancer.seen" 02.43.23 Join spermmme [0] (~spermmme@modemcable182.173-176-173.mc.videotron.ca) 02.43.31 Part spermmme 02.43.58 Join d00d [0] (~d00d@modemcable182.173-176-173.mc.videotron.ca) 02.44.51 # Hello im getting i/o error when trying to backup bootloader or installing rockbox 02.45.17 # formatted sd card in fat 32 mbr 02.45.52 # fiio m3k 02.54.46 Quit d00d () 03.21.53 *** Saving seen data "./dancer.seen" 04.09.15 # on windows ? 04.09.32 # maybe run whatever you do as administrator/root 04.36.17 Quit JanC (Read error: Connection reset by peer) 04.36.17 Quit amiconn (Read error: Connection reset by peer) 04.36.56 Join JanC [0] (~janc@user/janc) 04.37.05 Join amiconn [0] (jens@p200300ea870d1900305e95fffec66ff3.dip0.t-ipconnect.de) 05.08.04 Join IPG [0] (~InvoxiPla@2.122.6.66) 05.21.56 *** Saving seen data "./dancer.seen" 06.11.54 Join dnickc [0] (~dnickc@d515269EF.access.telenet.be) 07.17.46 Join dconrad [0] (~dconrad@152.117.104.216) 07.21.59 *** No seen item changed, no save performed. 07.22.20 # _bilgus_: Yes, that's correct. However, that only seems to apply while the device is running. At boot, it seems to detect the extension cord itself. 07.22.39 Join acidsys [0] (~crameleon@openSUSE/member/crameleon) 07.24.30 # My guess was they check for continuity across the ground pin (the sleeve, I think it's called)? 07.25.43 # So ...maybe... something to do with the way we're polling the state of those pins (over i2c)...? 07.39.01 Join rasher [0] (~rasher@user/rasher) 07.44.45 # Actually, if I hold the extension cord in the correct position (due to my headphone port being damaged... which maybe has something to do with the fact I dropped it the other day...) It detects the headphones both being plugged in and unplugged 07.45.29 # However the line-out seems to "latch" until the extension is pulled out of the port 07.52.03 # https://github.com/Rockbox/rockbox/blob/8c6b579b32072dfdf07c5859917262654bb55e98/firmware/target/mips/ingenic_x1000/erosqnative/button-erosqnative.c#L82-L121 08.06.43 Quit dconrad (Remote host closed the connection) 09.22.02 *** Saving seen data "./dancer.seen" 09.29.23 Quit dnickc (Ping timeout: 264 seconds) 10.04.59 Join Xeha [0] (~Xeha@user/Xeha) 10.25.34 Join davisr [0] (~davisr@fsf/emeritus/davisr) 11.22.06 *** Saving seen data "./dancer.seen" 11.25.31 # dconrad: honestly, this sounds like the classic "contact switch hooked up to a gpio" scenario 11.26.59 # that needs to be either polled or hw trigger an interrupt if the state changes 11.27.51 # (eg maybe the hw interrupt can only be set to trigger if rising, or falling, but not both? so when the state changes you also have to switch the polarity of the interrupt?) 11.31.55 # ok, so the code polls the AXP192's GPIO state once a second. 11.32.40 # hmm. looks like there's a data race of sorts between the headphones_inserted and lineout_inserted 11.33.12 # the code tends to call them back to back but whichever one is called first will effectively prevent the later from ever working 11.34.00 # because hep_inserted will set the old value 11.34.21 # so when lo_inserted is called, old == new so it doesn't need to change anything? 11.39.31 # digging further, I think I'm wrong. 11.42.18 # <_bilgus_> speachy, I came to similar conclusion first time thru but it actually uses a bit for each and they share it properly 11.45.56 # <_bilgus_> debounce was my next thought as I recall something similar here: https://gerrit.rockbox.org/r/c/rockbox/+/2749 11.46.57 # <_bilgus_> but maybe there are several mechanisms at play there but the code there seems sound 11.48.34 # <_bilgus_> do we have board pics of the ErosQ? 11.49.53 # ....which revision? Heh. 11.50.29 # I have an older-gen one that I could disassemble but IIRC this is about the newer ones. 12.00.21 # <_bilgus_> both would be even better but yeah the newer 12.36.41 Quit q3k (Ping timeout: 268 seconds) 13.21.02 Join lebellium [0] (~lebellium@2a01cb0405d07f0015a29ff3f6ff714c.ipv6.abo.wanadoo.fr) 13.22.08 *** Saving seen data "./dancer.seen" 13.34.35 Join dconrad_phone [0] (~dconrad_p@184.170.163.35) 13.36.40 # I may have pics of the v2 board here before long anyway... I lost the left channel on the headphone out, so the jack is more damaged than I thought 13.37.07 # luckily I have another board I can hopefully scavenge a jack off of 13.37.50 # what trips me up too is that this definitely used to work 13.39.04 Quit dconrad_phone (Client Quit) 15.22.09 *** Saving seen data "./dancer.seen" 15.42.38 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) 15.57.55 Quit wLLm (Ping timeout: 246 seconds) 15.59.39 Join wLLm [0] (~wLLm@2a10:3781:3ed0::3) 16.28.35 Join dconrad_phone [0] (~dconrad_p@184.170.163.35) 16.29.22 # so I've got the v2 erosq open and a microscope if we want pics of anything in particular 16.32.55 # I did manage to get my left channel working again (a pad had lifted off the board, luckily there's an identical pad on the other side of the jack I could jumper to) 16.33.21 # however the hp detection is still weird, I can't see a physical switch 16.36.52 Quit dconrad_phone (Quit: Connection closed) 17.21.51 Join dnickc [0] (~dnickc@d515269EF.access.telenet.be) 17.22.12 *** Saving seen data "./dancer.seen" 17.45.17 Quit dnickc (Ping timeout: 240 seconds) 17.47.17 Quit lebellium (Quit: Leaving) 18.35.46 # <_bilgus_> thta swhat I was wondering with the board pics 18.42.57 Join dconrad [0] (~dconrad@152.117.104.216) 18.46.29 # _bilgus_: https://imgur.com/a/eNFTCpE here's just an overview 18.47.53 # so turns out there's two situations where a headphone extension with nothing plugged in on the other end (open circuit) is detected correctly in the line out port: 18.47.57 # 1) at boot 18.48.47 # 2) if I switch the new "stereo switch behavior" setting, so whatever gets run in the callback there 18.49.18 # so it's not electrically impossible or anything 18.50.04 # and unplugging a headphone extension (open circuit on the other end) is always detected correctly 18.51.09 # I think the detection mechanism on the headphone port on my particular unit is hella broken, so that's right out 19.10.31 Quit gevaerts (Ping timeout: 255 seconds) 19.11.51 Join gevaerts [0] (~fg@user/gevaerts) 19.22.16 *** Saving seen data "./dancer.seen" 19.26.27 Join massiveH [0] (~massiveH@2600:4040:a982:c800:10c5:a87e:1234:7d8b) 19.43.17 Quit gevaerts (Ping timeout: 240 seconds) 19.50.41 Join gevaerts [0] (~fg@user/gevaerts) 20.20.25 Quit davisr (Remote host closed the connection) 20.34.11 Quit gevaerts (Ping timeout: 252 seconds) 20.34.28 Join gevaerts [0] (~fg@user/gevaerts) 21.16.51 Quit baltazar (Ping timeout: 268 seconds) 21.18.06 Join baltazar [0] (~baltazar@user/baltazar) 21.22.18 *** Saving seen data "./dancer.seen" 22.23.46 Quit dconrad (Remote host closed the connection) 22.30.12 Quit advcomp2019 (Read error: Connection reset by peer) 22.39.49 Quit massiveH (Quit: Leaving) 23.04.49 Join dconrad [0] (~dconrad@152.117.104.216) 23.22.20 *** Saving seen data "./dancer.seen" 23.32.48 Quit dconrad (Remote host closed the connection) 23.33.24 Join dconrad [0] (~dconrad@152.117.104.216) 23.38.23 Quit dconrad (Ping timeout: 264 seconds) 23.39.55 Quit jn (Ping timeout: 246 seconds) 23.40.24 Join jn [0] (~quassel@2001-4dd3-c067-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de) 23.40.24 Quit jn (Changing host) 23.40.24 Join jn [0] (~quassel@user/jn/x-3390946) 23.54.55 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)