Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2024-06-10

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] (
02:43:31 Part spermmme
02:43:58 Join d00d [0] (
02:44:51d00dHello im getting i/o error when trying to backup bootloader or installing rockbox
02:45:17d00dformatted sd card in fat 32 mbr
02:45:52d00dfiio m3k
02:54:46 Quit d00d ()
03:21:53***Saving seen data "./dancer.seen"
04:09:15sporkon windows ?
04:09:32sporkmaybe 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] (
05:08:04 Join IPG [0] (~InvoxiPla@
05:21:56***Saving seen data "./dancer.seen"
06:11:54 Join dnickc [0] (
07:17:46 Join dconrad [0] (~dconrad@
07:21:59***No seen item changed, no save performed.
07:22:20dconrad_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:30dconradMy guess was they check for continuity across the ground pin (the sleeve, I think it's called)?
07:25:43dconradSo ...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:45dconradActually, 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:29dconradHowever the line-out seems to "latch" until the extension is pulled out of the port
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:31speachydconrad: honestly, this sounds like the classic "contact switch hooked up to a gpio" scenario
11:26:59speachythat needs to be either polled or hw trigger an interrupt if the state changes
11:27:51speachy(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:55speachyok, so the code polls the AXP192's GPIO state once a second.
11:32:40speachyhmm. looks like there's a data race of sorts between the headphones_inserted and lineout_inserted
11:33:12speachythe code tends to call them back to back but whichever one is called first will effectively prevent the later from ever working
11:34:00speachybecause hep_inserted will set the old value
11:34:21speachyso when lo_inserted is called, old == new so it doesn't need to change anything?
11:39:31speachydigging 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:
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:53speachy....which revision? Heh.
11:50:29speachyI 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] (
13:22:08***Saving seen data "./dancer.seen"
13:34:35 Join dconrad_phone [0] (~dconrad_p@
13:36:40dconrad_phoneI 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:07dconrad_phoneluckily I have another board I can hopefully scavenge a jack off of
13:37:50dconrad_phonewhat 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] (
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@
16:29:22dconrad_phoneso I've got the v2 erosq open and a microscope if we want pics of anything in particular
16:32:55dconrad_phoneI 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:21dconrad_phonehowever 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] (
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@
18:46:29dconrad_bilgus_: here's just an overview
18:47:53dconradso 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:57dconrad1) at boot
18:48:47dconrad2) if I switch the new "stereo switch behavior" setting, so whatever gets run in the callback there
18:49:18dconradso it's not electrically impossible or anything
18:50:04dconradand unplugging a headphone extension (open circuit on the other end) is always detected correctly
18:51:09dconradI 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@
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@
23:38:23 Quit dconrad (Ping timeout: 264 seconds)
23:39:55 Quit jn (Ping timeout: 246 seconds)
23:40:24 Join jn [0] (
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)

Previous day | Next day