#rockbox 2021-03-05

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 2021-03-05

00:03:01	_bilgus	bout time
00:03:11	_bilgus	builtin and the all green
00:04:32	***	Saving seen data "./dancer.seen"
00:04:34	braewoods	speachy: i've researched the problem. i think hid power is the wrong solution... after reading linux source, i found out there's two protocols for device battery reporting over USB.
00:04:52	braewoods	the logitech one which appears to be bound to logitech product/vendor IDs...
00:04:57	braewoods	so no buena for that reaso
00:05:13	braewoods	and some kind of HID battery strength thing
00:05:27	braewoods	it appears it can be grafted over the existing HID driver
00:05:30	braewoods	i'll look into it
00:11:12	braewoods	wow. battery strength is in a part of the main HID spec.
00:11:27	braewoods	really obscure but it's there
00:13:08	fs-bluebot	Build Server message: New build round started. Revision 925dc59126, 293 builds, 9 clients.
00:22:38	fs-bluebot	Build Server message: Build round completed after 570 seconds.
00:22:42	fs-bluebot	Build Server message: Revision 925dc59126 result: All green
02:00
02:04:34	***	No seen item changed, no save performed.
02:44:05		Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
03:00
03:05:37		Quit Saijin-Naib (Ping timeout: 260 seconds)
03:21:10		Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-9028-65b9-473d-af64.res6.spectrum.com)
04:00
04:04:38	***	Saving seen data "./dancer.seen"
04:28:00	braewoods	Huh. It was seriously that easy?
04:28:14	braewoods	why didn't we do this sooner?
04:28:48	braewoods	speachy: i have a working prototype, only issue is i'm not too sure when i should deploy the updates
04:45:37	braewoods	incidently
04:46:09	braewoods	i think we can enable usb hid in charging only mode if this works out acceptably
04:46:19	braewoods	and just not send reports for the other HID types
04:46:26	braewoods	only send battery reports
04:50:37		Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:00
05:31:42		Quit pamaury (Remote host closed the connection)
05:34:40		Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
06:00
06:03:02	speachy	braewoods: once per second?
06:04:41	***	Saving seen data "./dancer.seen"
06:27:15		Quit ArsenArsen_ (Remote host closed the connection)
06:27:38		Join ArsenArsen [0] (~Arsen@fsf/member/ArsenArsen)
06:33:02		Quit TorC (Ping timeout: 264 seconds)
06:38:33		Quit pamaury (Ping timeout: 258 seconds)
06:53:59		Join TorC [0] (~Tor@fsf/member/TorC)
07:00
07:03:30		Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
07:19:09		Quit speachy (Quit: WeeChat 3.0.1)
07:47:36		Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
08:00
08:04:44	***	Saving seen data "./dancer.seen"
08:38:08	_bilgus	So I think we need a plan for this voice file issue as you daid its only going to get worse
08:38:14	_bilgus	said*
08:38:49	_bilgus	I'm thinking maybe better compression might buy us some time
08:39:30	_bilgus	probably though its need to be that plugins have their own voice file that we load to the plugin buffer to keep it off of core
08:40:40	_bilgus	either that or we need to incrementally load the voices but that could quickly get hairy
08:44:03		Quit massiveH (Quit: Leaving)
09:00
09:56:56		Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-43568247.dyn.optonline.net)
10:00
10:04:40		Join speachy [0] (40eebded@64.238.189.237)
10:04:46	***	Saving seen data "./dancer.seen"
10:06:32	speachy	_bilgus, It's a pretty hairy problem.. right now there's no way to specify string/voice scope, and given how much functionality is implemented via seamless plugin loads/unloads, it'll get rather hairy to swap voice stuff in and out.
10:07:29	speachy	in other words, do we generate per-plugin language+voice files, and [re]load that stuff every time we launch a plugin?
10:08:56	speachy	better compression might help, but it'll come at the expense of overhead (has to coexist with the main audio codec running) −− and speex will be hard to beat.
10:21:52	speachy	Our only real avenue with speex is to drop quality (even if just going to 8KHz narrowband vs the current 16KHz). If we are to ditch speex, our only real option is Opus, which will give us equivalent quality at a lower bitrate, but the codec is more heavyweight
10:31:59	speachy	the m200 has 1(!) MB only, the old sansa AMSes have 2MB, and the AMSv2s have 8MB. (most of the hosted targets are limited to 8MB too)
10:33:27	speachy	oh, for speex, going from the current 16KHz encoded stuff to 8KHz encoding knocks the voice size down by about 1/3
10:34:57	speachy	so maybe that's a compromise we can make in the short term −− for <=8MB players, switch to narrowband encoding for speech?
10:36:30	_bilgus	speachy the voice subsystem has the ability to incrementally load voice files
10:37:32	_bilgus	but I'm not so sure this is what is going on anymore either
10:38:00	speachy	yeah.. if the engine only loads voice stuff on demand, splitting things up shouldn't matter, right?
10:38:23	_bilgus	well it sets its own buffer
10:38:44	_bilgus	and I don't think that has changed
10:38:56	_bilgus	the size of it that is
10:40:02	_bilgus	so I'm chasing a symptom but is that the cause or is someone else behaving badly now that the memory is getting tighter
10:40:06	speachy	going from q7 to q6 saves about 10% only.
10:40:25	speachy	the voice buffer size shouldn't matter if it only loads what it needs
10:40:33	_bilgus	exactly
10:40:41	speachy	since individual voice strings haven't really changed
10:41:33	_bilgus	I backed off the dumping of the voice buffer to only < 1KB left and guess what it still returns -2
10:41:48	speachy	aha, so a red herring..
10:41:53	speachy	buffer fragmentation?
10:42:21	_bilgus	its supposed to compress and make contig what it can
10:42:28	_bilgus	but maybe someone is stubborn
10:42:51	speachy	still, would be good to dump the buflib allocation state to see what's going on
10:43:31	speachy	other than your viewport rework I can't recall any major work to core functionality for some time
10:43:57	speachy	just the incremental bloat of fixing bugs and feature additions
10:44:23	_bilgus	it could very well be that upping the memory pressure
10:44:33	speachy	oh! since I made that audo_hard_stop() change in rolo I haven't had the x3 hang on rolo at all.
10:45:08	_bilgus	awesome!
10:45:28	speachy	(except when I accidently loaded up an image with my WIP buffer realignment stuff in the FAT code)
10:45:49	_bilgus	I'm pretty sure the buf lib already has a sentinel plastered through it
10:45:53	speachy	(following the "it compiled therefore it must work" mentality)
10:49:26	_bilgus	speachy do we have any older builds with voice files than whats up on rbdev?
10:50:08	speachy	_bilgus, IIRC each formal release had an english .voice that went along with it
10:50:29	speachy	but the infra only keeps one calendar month of dailies.
10:51:03	_bilgus	ah ok so it'll be a slog to bisect
10:51:34	speachy	oh! that reminds me −− you're using US Engrish? Did you try the default English lang+voice?
10:51:58	speachy	(wondering if there's some sort of lingering issue caused from switching languages at startup)
10:51:58	_bilgus	sadly if its a badly behaving existing bug that would solve nothing
10:52:17	_bilgus	the us eng file doesn't work
10:52:25	_bilgus	it says wrong ver
10:52:47	_bilgus	brit eng works and loaded at start through all
10:53:36	speachy	did you only try it on the clipzip, or does it also fail on the x3?
10:54:00	speachy	(meaning the english-us voice)
10:55:38	_bilgus	only the clipzip I can try one of the others
10:58:57	speachy	I'm grabbing the dailies for the x3
11:00
11:00:43	_bilgus	rocker says: failed loading voice
11:01:05	speachy	x3 does it too.
11:02:14	speachy	wtf.. when did this break?
11:09:19	speachy	the oldest daily breaks too
11:10:23	speachy	... which is one day after I rewrote the daily voice script to be parallelizable
11:12:37		Quit tomato (Quit: Ping timeout (120 seconds))
11:12:51	_bilgus	lol
11:15:08	speachy	that's just the wrapper for the infra though; I built a new english-us just now and it's also failing, error 4
11:25:22	speachy	ok, the expected/actual string IDs are wrong.
11:27:59	_bilgus	hmm like how wrong?
11:28:43	speachy	this tells me the preprocessing pass that backfills missing strings is not working properly
11:29:11	speachy	id1 is 725 (expected 729), id2 is 130 (vs 131)
11:29:21		Quit Saijin_Naib (Read error: Connection reset by peer)
11:29:26	_bilgus	i thought that was done first for that reason
11:29:30	speachy	coincidentally english-us is missing 4 strings
11:32:57		Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
11:41:20	speachy	the point where things broke appears to be the usb mode prompt
11:54:00		Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
12:00
12:04:47	***	Saving seen data "./dancer.seen"
12:09:06	speachy	for some reason the language enum header isn't matching what genlang is generating.
12:10:09		Join ac_laptop [0] (~ac_laptop@186.2.247.129)
12:10:46	speachy	okay, the problem is in genlang.
12:16:04	speachy	nope, I committed a bad english-us.
12:16:09	speachy	okay. easy fix.
12:19:44	braewoods	speachy: sure, but not sure where to embed that.
12:20:29	braewoods	speachy: i tried embedding it in power history but it never got called
12:20:37	fs-bluebot	Build Server message: New build round started. Revision 83111eeece, 293 builds, 9 clients.
12:21:01	speachy	_bilgus, this build will fix english-us voice generation.
12:21:39		Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-9028-65b9-473d-af64.res6.spectrum.com)
12:21:46	speachy	genlang should have handled this better but at the end of the day, it was bad data being fed into it.
12:23:14	braewoods	oh wait
12:23:21	braewoods	power history runs every minute
12:23:27	braewoods	dur
12:28:34	speachy	english-us has been broken since mid-november. nice.
12:28:56	speachy	guess that shows how many folks actually used it.
12:30:07	fs-bluebot	Build Server message: Build round completed after 570 seconds.
12:30:10	fs-bluebot	Build Server message: Revision 83111eeece result: All green
12:37:58	fs-bluebot	Build Server message: New build round started. Revision 0c958d2b4a, 293 builds, 8 clients.
12:38:39	_bilgus	well see by default they would use english gb
12:38:56	_bilgus	but how many times was it downloaded?
12:40:20	braewoods	1, 2, 3, 3 downloads! uahahahaha
12:41:23	_bilgus	us?
12:41:42	braewoods	no idea
12:41:43		Quit ac_laptop (Ping timeout: 245 seconds)
12:41:47	braewoods	anyway
12:42:02		Quit pamaury (Ping timeout: 264 seconds)
12:42:07	speachy	ok, found a proper fix in the updatelang to compensate for this
12:42:16	speachy	now it'll get flagged properly
12:42:24	braewoods	cool, HID battery strength is working in my test build
12:43:33	_bilgus	I found my weird easily reproducible bug in announce_status I was deleting the wrong trackchange callback
12:44:37	speachy	bbiab.
12:47:50	fs-bluebot	Build Server message: Build round completed after 593 seconds.
12:47:53	fs-bluebot	Build Server message: Revision 0c958d2b4a result: All green
12:47:54	fs-bluebot	Build Server message: New build round started. Revision bac897381c, 293 builds, 8 clients.
12:52:12	_bilgus	braewoods, do you plan to integrate that with rbpatcher to show battery level?
12:52:28	braewoods	_bilgus: rbpatcher?
12:52:45	braewoods	what's that?
12:53:06	_bilgus	the rb installer
12:53:21	braewoods	why would i need to support it in the installer?
12:53:48	braewoods	right now my example just does this
12:54:06	braewoods	i extend the hid driver so it can emit the battery strength reports
12:54:24	braewoods	then i add code to powermgmt.c so it will send those reports periodically as part of its thread code
12:54:49	braewoods	if connected to usb those should always be sent
12:54:58	braewoods	assuming hid is active
12:55:24	_bilgus	ok maybe I misunderstand then who is your consumer on the pc side? the OS?
12:55:29	braewoods	the OS, yes
12:55:47	braewoods	at least on Linux, the kernel consumes these reports to provide a battery device
12:55:53	_bilgus	ad it will? show a battery level beside the device?
12:56:26	braewoods	essentially, at least in the GUI for the DE
12:56:43	braewoods	we might be able to send them to the installer as well?
12:56:51	braewoods	though i wouldn't know how
12:57:04	braewoods	i mean, RB would have to be installed first
12:57:14	_bilgus	I think I remember seeing that in windows I didn't realize linux had it
12:57:29	fs-bluebot	Build Server message: Build round completed after 575 seconds.
12:57:31	braewoods	yes, it does, and there's multiple ways to achieve it over usb
12:57:31	fs-bluebot	Build Server message: Revision bac897381c result: All green
12:57:48	braewoods	HID Power is technically one but most would interpret that as a UPS which we ar enot
12:58:04	braewoods	wasn't sure it would work properly and is somewhat complex
12:58:05	_bilgus	I just figured you'd send it to the installer to decide if the battery level was too low and to display a meter next to a device
12:58:27	braewoods	well, if the OS exposes it, the installer might be able to find it through host APIs
12:58:34	braewoods	on Linux it is definitely possible
12:58:51	braewoods	we'll just have to see how this works out
12:59:09	braewoods	i don't know enough about host APIs to know if Battery Strength is the best cross platform solution
12:59:11	braewoods	right now
12:59:20	braewoods	just trying to keep it simple and get it working
12:59:44	braewoods	there was also the logitech protocol but that is tied to product and vendor IDS
12:59:48	braewoods	which i didn't want to tamper with
12:59:58	braewoods	the only standard method i found was battery strength
13:00
13:00:02	braewoods	and obscure part of the HID spec
13:00:26	braewoods	but, devices CAN use it to report basic battery status
13:00:36	braewoods	it's purely limited to a % report but that's enough
13:00:51	braewoods	it works by having you define a range and send reports as a value in that range
13:00:58	braewoods	the % is derived from that
13:01:04	braewoods	but since we already work in percent
13:01:08	braewoods	i made the range 0 to 100
13:01:57	braewoods	_bilgus: maybe we can use it but i'm not an expert in host APIs for this
13:02:11	braewoods	just getting the reports generated is a good place to start
13:03:32	braewoods	https://gerrit.rockbox.org/r/c/rockbox/+/3180
13:03:35	braewoods	_bilgus: ^
13:07:33	braewoods	though it's weird
13:07:46	braewoods	if the reports are right, my battery strength is decreasing while connected to USB
13:07:49	braewoods	what's up with that
13:11:03		Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be)
13:11:25	braewoods	_bilgus: can you test this on a windows host?
13:11:42		Quit jdarnley (Ping timeout: 260 seconds)
13:15:14	_bilgus	no I don't have one
13:15:28	_bilgus	and I haven't even set up a VM
13:22:10	braewoods	ok fair enough
13:22:14	braewoods	i'll give it a spin later probably
13:22:19	braewoods	i just don't have windows handy
13:22:28	braewoods	or maybe speachy can do a test use
13:22:33	braewoods	but in any case
13:22:42	braewoods	i'm kinda surprised this wasn't already implemented
13:22:57	braewoods	it was available for over 20 years, though maybe not in the OS kernels
13:24:50	braewoods	in any case though
13:25:10	braewoods	if this works as expected we might be able to leverage it in rbutil, assuming that's what you meant?
13:25:33		Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
13:26:11	_bilgus	yep
13:26:42	braewoods	only helps if RB is already installed though so we can't rely on it to be present
13:26:51	braewoods	even so
13:26:54	braewoods	we can look for it
13:27:13	braewoods	use it if available but otherwise use old behavior
13:28:02	braewoods	_bilgus: just getting weird results. guess it's a side effect of the roller coaster that is the battery reporting stuff.
13:28:27	braewoods	it dropped to 75% after being disconnected
13:28:35	braewoods	reconnected it and it slowly rose to 83%
13:28:50	braewoods	it was at 91% earlier and dropped to 83% after being connected
13:29:13	braewoods	the reporting is at least working correctly even if the internal battery data is a bit weird
13:31:14	_bilgus	sounds about like the typical behavior
13:32:37	braewoods	it won't be 100% accurate due to the simple nature of the protocol but it's probably the best option for RB
13:33:30	braewoods	it's just funny to see upower says it is "discharging"
13:33:36	braewoods	when it's actually charging or so
13:36:33	braewoods	https://dpaste.com/9W65ZCFJG
13:36:37	braewoods	upower report
13:37:18	braewoods	it thinks it is a wireless keyboard battery or so
13:37:31	braewoods	good enough for me though
14:00
14:04:49	***	Saving seen data "./dancer.seen"
14:09:53		Quit pamaury (Ping timeout: 265 seconds)
14:16:34	braewoods	hm
14:16:50	braewoods	nah
14:22:52		Quit Saijin_Naib (Remote host closed the connection)
14:28:11	speachy	braewoods: nice!
14:28:28	braewoods	it was a lot simpler than i expected
14:28:39	braewoods	at least to get a minimal reporting setup
14:28:50	braewoods	if you want more detailed approach something more complex would have to be used
14:29:07	braewoods	i do know though that HID Power has two disadvantages
14:29:23	braewoods	more complex and would require a second end point alongside regular HID
14:29:38	braewoods	this approach lets us just use the existing HID endpoint, conserving precious resources
14:30:52	speachy	do you know how upower comes up with that 'discharging' state?
14:31:35	speachy	or is it just "value went up[down] since the last one"?
14:31:51	braewoods	speachy: kernel report.
14:31:55	braewoods	let me find the code.
14:32:26	speachy	since there doesn't seem to be anything in the HID definitions that let us indicate that
14:32:33	braewoods	there isn't
14:32:39	braewoods	it only lets us report battery level
14:32:59	braewoods	https://github.com/torvalds/linux/blob/master/drivers/hid/hid-input.c#L423
14:33:01	braewoods	here it is
14:33:15	braewoods	it is derived from the latest reported capacity
14:33:40	braewoods	so it can only report full, discharging, or unknown
14:33:52	speachy	hmm, that's.. a little braindead.
14:34:09	braewoods	it is, but that's common in Linux drivers when they don't have enough information.
14:34:20	braewoods	they have to fit the generic framework
14:34:34	braewoods	and hid battery strength only reports the current level
14:35:22	braewoods	logitech's protocol is more advanced but afaik only detected if we use logitech product ids
14:35:27	speachy	yeah, but by keeping aroudn the previous state you an at least tell if it's going up or down.
14:36:25	braewoods	usually vendor extensions are gated to the vendor's products so
14:36:30	braewoods	we'd have to pretend to be them to use them
14:37:00	braewoods	the only other way i know to report battery status is to use HID Power
14:37:18	braewoods	but, again, it uses a separate endpointer
14:37:28	braewoods	and we might be confused for a UPS
14:37:30	braewoods	which we are ot
14:38:03	braewoods	looking through upower, it considers HID Power to be a UPS if it uses the power device usage page
14:38:11	braewoods	so we'd probably just implement the battery system usage page
14:38:24	braewoods	speachy: you want me to try to implement HID Power?
14:38:26	braewoods	or is this enough?
14:38:33	braewoods	HID Power would be more accurate
14:39:23	braewoods	but i think we should only have one of these methods
14:39:36	braewoods	as they provide the same basic thing
14:40:45	speachy	I think this is plenty good
14:41:56	braewoods	i still need to confirm how the other hosts interpret it
14:42:07	braewoods	but Linux reports it as a power supply under /sys
14:42:17	braewoods	which upower then picks up on
14:45:02		Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-6042-5603-0233-f27a.res6.spectrum.com)
14:45:06	braewoods	speachy: can you test it on a windows host?
14:45:20	braewoods	see if the battery is even picked up
14:45:29	speachy	I only have a Win7 VM.
14:45:34	braewoods	I see.
14:45:42	braewoods	maybe USB passthrough
14:45:44	speachy	and $dayjob Win10, but its USB is locked down.
14:46:04	braewoods	in that case i'll do a test later
14:46:16	braewoods	just need to reinstall windows on a spare PC
14:46:16	speachy	(passthrough is fine, it's just that I don't have much faith in Win7 picking it up)
14:46:27	braewoods	if it doesn't then it doesn't
14:46:32	braewoods	main concern i had was windows 10
14:51:21	braewoods	speachy: once this is merged I was hoping to change charging_only mode to enable HID as well but only send our battery reports in this mode
14:51:50	braewoods	that seems to work since our HID driver only sends reports when prompted by other parts of RB
14:52:09	speachy	it's a good idea in principle; in practice it may be a lot trickier −− IIRC chargeonly doesn't export _any_ endpoints.
14:52:27	speachy	you may have to contend with individual target usb drivers
14:52:30	braewoods	indeed it doesn't; perhaps we can just make that mode only enable HID driver
14:52:51	speachy	but yes, that is a good natural progression
14:52:53	braewoods	in any case we do need to develop a way to selectively enable them due to endpoint limits
14:53:12	braewoods	just wasn't a problem before to a limited number of drivers
14:53:17	braewoods	but with me eventually adding MTP
14:53:25	braewoods	a complex project for another day
14:53:35	braewoods	we will need to revisit how we select the drivers to use
15:00
15:09:44		Quit TheLemonMan (Read error: Connection reset by peer)
15:10:09		Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
15:13:07	DEBUG	Received signal 15 (SIGTERM), terminating (snapshot: transfer.c line 304)
15:13:07	***	Cleanup
15:13:07	***	Saving seen data "./dancer.seen"
15:13:07	***	Exit
15:17:50	***	Started Dancer V4.16
15:17:50	***	Connected to irc.freenode.net on port 6667
15:17:50	***	Logfile for #rockbox started
15:17:54	Mode	"logbot :+Ri" by logbot
15:18:00	***	Server message 501: 'logbot :Unknown MODE flag'
15:18:01		Join logbot [0] (~rockbox@stuffed.shaftnet.org)
15:18:01		Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
15:18:01		Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-6042-5603-0233-f27a.res6.spectrum.com)
15:18:01		Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be)
15:18:01		Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
15:18:01		Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
15:18:01		Join speachy [0] (40eebded@64.238.189.237)
15:18:01		Join TorC [0] (~Tor@fsf/member/TorC)
15:18:01		Join ArsenArsen [0] (~Arsen@fsf/member/ArsenArsen)
15:18:01		Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019)
15:18:01		Join f1refly [0] (~f1refly@dynamic-077-008-131-029.77.8.pool.telefonica.de)
15:18:01		Join kadoban [0] (kadobanemp@gateway/shell/matrix.org/x-iaialaudtoihlpte)
15:18:01		Join mud [0] (kadobanmat@gateway/shell/matrix.org/x-vshgkgtjqjjszdqu)
15:18:01		Join ccf-100 [0] (ccf-100mat@gateway/shell/matrix.org/x-nuydoyusulzbivvh)
15:18:01		Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-jqhspsdmcotzpgle)
15:18:01		Join mendel_munkis [0] (~mendelmun@ool-43568247.dyn.optonline.net)
15:18:01		Join fauweh [0] (~root@ithaqua.unzane.com)
15:18:01		Join aevin [0] (eivindsy@unaffiliated/aevin)
15:18:01		Join XDjackieXD [0] (~jackie@irc.chaosfield.at)
15:18:01		Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
15:18:01		Join Galois [0] (djao@efnet-math.org)
15:18:01		Join Soap_ [0] (~Soap@rockbox/staff/soap)
15:18:01		Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
15:18:01		Join atsampson [0] (~ats@cartman.offog.org)
15:18:01		Join ParkerR [0] (ParkerR@unaffiliated/parkerr)
15:18:01		Join rudi_s [0] (~simon@bmi.informatik.uni-erlangen.de)
15:18:01		Join prg3 [0] (~prg@deadcodersociety/prg318)
15:18:01		Join Strife89 [0] (~quassel@adsl-74-250-153-79.ags.bellsouth.net)
15:18:01		Join spectrumanalyst [0] (~admin@198.46.152.45)
15:18:01		Join skrzyp [0] (~skrzyp@skrzyp.net)
15:18:01		Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
15:18:01		Join pixelma [0] (marianne@rockbox/staff/pixelma)
15:18:01		Join amiconn [0] (jens@rockbox/developer/amiconn)
15:18:01		Join rasher [0] (~rasher@rockbox/developer/rasher)
15:18:01		Join copper [0] (~copper@unaffiliated/copper)
15:18:01		Join nast [0] (~nast@139.64.244.18)
15:18:01		Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
15:18:01		Join daswf852 [0] (~daswf852@unaffiliated/dwf)
15:18:01		Join Tsesarevich [0] (sid83162@fluxbuntu/founder/joejaxx)
15:18:01		Join fs-bluebot [0] (~fs-bluebo@55d4a316.access.ecotel.net)
15:18:01		Join Romster [0] (~romster@unaffiliated/romster)
15:18:01		Join CR0W [0] (~narf@unaffiliated/em64t)
15:18:01		Join xcin [0] (~x@159.203.132.140)
15:18:01		Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se)
15:18:01		Join toruvinn [0] (~toruvinn@77-255-90-179.adsl.inetia.pl)
15:18:01		Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:6195:b89b:f6c1:6d57)
15:18:01		Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
15:18:01		Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr)
15:18:01		Join tchan [0] (~tchan@lunar-linux/developer/tchan)
15:18:01		Join trfl [0] (~ed@static.59.110.40.188.clients.your-server.de)
15:18:01		Join Topy44 [0] (up1sYgB63Z@bellatrix.uberspace.de)
15:18:01		Join shapeless [0] (shapeless@2001:41d0:401:3100::8a33)
15:18:01		Join ender\| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3)
15:18:01		Join jerwin [0] (~flippy-fl@unaffiliated/flippy)
15:18:01		Join klock [0] (~freeklock@unaffiliated/klock)
15:18:01		Join igitoor [0] (igitur@unaffiliated/contempt)
15:18:01		Join Lonoxmont [0] (~lonoxmont@024-180-058-254.res.spectrum.com)
15:18:01		Join Moarc [0] (~chujko@a105.net128.okay.pl)
15:18:01		Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
15:18:01		Join M-iam-some0nee[m [0] (m-iam-some@gateway/shell/matrix.org/x-wppdpteiyxyvykqt)
15:18:01		Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
15:18:01		Join KalBot1 [0] (~matrixirc@connolly.tech)
15:18:01		Join Slasheri [0] (~miipekk@rockbox/developer/Slasheri)
15:18:01		Join plum [0] (~plum@unaffiliated/plum)
15:18:01		Join JanC [0] (~janc@lugwv/member/JanC)
15:18:01		Join melmothX [0] (~marco@unaffiliated/melmothx)
15:18:01		Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567)
15:18:01		Join Natch [0] (~natch@c-b471e255.014-297-73746f25.bbcust.telenor.se)
15:18:01		Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr)
15:18:01		Join APLU [0] (~mulx@eva.aplu.fr)
15:18:01		Join Rondom [0] (~rondom@modo.nonmodosedetiam.net)
15:18:01		Join gevaerts [0] (~fg@rockbox/developer/gevaerts)
15:18:01		Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
15:18:01		Join braewoods [0] (~braewoods@learnprogramming/staff/braewoods)
15:18:01		Join alexbobp [0] (~alex@meowface.org)
15:18:01		Join emacsoma1 [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
15:18:01		Join bleb [0] (~cm@unaffiliated/bleb)
15:18:01		Join bzed [0] (~bzed@shell.bzed.at)
15:18:01		Join asabas [0] (~asaba@103.113.159.184)
15:18:01		Join kirvesAxe [0] (kirvesaxe@aulis.sange.fi)
15:18:01		Join msc68 [0] (~quassel@204.48.30.120)
15:18:01		Join berber [0] (~berber@v2202101107577140883.nicesrv.de)
15:18:01		Join lemon_jesus [0] (~lemon_jes@208.59.79.137)
15:18:01		Join benedikt93_ [0] (~quassel@unaffiliated/benedikt93)
15:18:01		Join __builtin [0] (~quassel@rockbox/developer/builtin)
15:18:01		Join k1w1 [0] (~k1w1@unaffiliated/k1w1)
15:18:01		Join Xeha [0] (~Xeha@unaffiliated/xeha)
15:18:01		Join hook54321 [0] (sid149355@gateway/web/irccloud.com/x-ubofpttnmhfxwudr)
15:18:01		Join beencubed [0] (~beencubed@209.131.238.248)
15:18:01		Join ecs [0] (esawady@d2evs.net)
15:18:01		Join RafiX [0] (rafix@junkcc.net)
15:18:01		Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de)
15:18:01		Join Skyrider [0] (~Skyrider@v220200567215119438.goodsrv.de)
15:18:01		Join galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549)
15:18:01		Join CommunistWitchDr [0] (quassel@024-217-039-226.res.spectrum.com)
15:18:01		Join funman [0] (~fun@rockbox/developer/funman)
15:18:01		Join @ChanServ [0] (ChanServ@services.)
15:18:01		Join vup [0] (~~~~@46.101.193.235)
15:18:01		Join SammysHP [0] (~SammysHP@faol.sammyshp.de)
15:18:01		Join ps-auxw [0] (~arneb@p548d56ce.dip0.t-ipconnect.de)
15:18:01		Join kugel_ [0] (~kugel@rockbox/developer/kugel)
15:18:01		Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at)
15:18:01		Join Barlow [0] (~barlow@unaffiliated/barlow)
15:18:01		Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net)
15:18:01		Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g)
15:18:01		Join gsora [0] (~gsora@unaffiliated/gsora)
15:18:01		Join dys [0] (~dys@aurora.ydns.eu)
15:18:01		Join _bilgus [0] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com)
15:18:01		Join rogeliodh [0] (~rogeliodh@rogeliodh.dev)
15:18:01		Join user890104 [0] (~Venci@freemyipod.org)
15:45:26		Quit jschwart (Ping timeout: 240 seconds)
15:52:08		Join bonfire [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net)
15:54:16		Join jschwart [0] (~quassel@julius.xs4all.nl)
16:00
16:10:34		Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be)
16:12:33		Quit J_Darnley (Ping timeout: 264 seconds)
16:16:23		Quit speachy (Quit: Connection closed)
16:50:21	braewoods	_bilgus: did you ever find that supplemental manual for the JZ4760B?
16:56:25		Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
17:00
17:05:18		Quit pamaury (Quit: No Ping reply in 180 seconds.)
17:06:35		Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
17:09:09		Quit pamaury (Read error: Connection reset by peer)
17:11:47		Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
17:17:54	***	Saving seen data "./dancer.seen"
17:29:44		Join ac_laptop [0] (~ac_laptop@186.2.247.129)
17:32:08		Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
17:38:23	_bilgus	braewoods, no unfortunately not
17:48:42	braewoods	_bilgus: what would it do for the RB ports?
17:48:51		Quit pamaury (Ping timeout: 272 seconds)
17:49:13	braewoods	it's strange that it wasn't part of the vendor's public docs
17:55:16		Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257)
17:56:30	_bilgus	I think it covers dma and a few other things
17:56:48	braewoods	ah
17:57:03	braewoods	i PMed someone i know that might be able to help but i haven't seen them active on IRC in awhile
17:57:28	braewoods	one of the few times i wish we knew someone from China =p
18:00
18:12:48		Quit lebellium (Quit: Leaving)
18:15:05		Quit Saijin_Naib (Disconnected by services)
18:15:09		Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-6042-5603-0233-f27a.res6.spectrum.com)
18:29:39		Quit Huntereb (Read error: Connection reset by peer)
18:31:39		Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7::69)
18:33:47		Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
18:41:55		Quit Saijin-Naib (Ping timeout: 240 seconds)
19:00
19:08:39		Join S\|h\|a\|w\|n [0] (~shawn156@unaffiliated/shawn156)
19:17:58	***	Saving seen data "./dancer.seen"
19:18:09		Quit pamaury (Ping timeout: 272 seconds)
19:28:20		Quit Huntereb (Read error: Connection reset by peer)
19:30:52		Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7::69)
19:33:02		Quit Huntereb (Read error: Connection reset by peer)
19:36:09		Join Huntereb [0] (~Huntereb@142-196-011-243.res.spectrum.com)
19:38:00		Quit Huntereb (Read error: Connection reset by peer)
19:41:24		Join Huntereb [0] (~Huntereb@142-196-011-243.res.spectrum.com)
20:00
20:04:08		Join speachy [0] (~speachy@209.2.65.77)
20:16:57		Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
20:29:38		Quit Huntereb (Ping timeout: 245 seconds)
20:32:59		Join Huntereb [0] (~Huntereb@142-196-011-243.res.spectrum.com)
20:34:51		Quit Huntereb (Read error: Connection reset by peer)
20:36:48		Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:6195:b89b:f6c1:6d57)
20:44:43		Quit Huntereb (Read error: Connection reset by peer)
20:44:56		Join Huntereb [0] (~Huntereb@2603-9001-5a04-bbe7-6195-b89b-f6c1-6d57.inf6.spectrum.com)
21:00
21:14:31	fs-bluebot	Build Server message: New build round started. Revision 9cf45374e0, 293 builds, 9 clients.
21:18:01	***	Saving seen data "./dancer.seen"
21:24:29	fs-bluebot	Build Server message: Build round completed after 598 seconds.
21:24:33	fs-bluebot	Build Server message: Revision 9cf45374e0 result: All green
21:26:48	speachy	I'm liking these 10min builds
21:33:11	braewoods	speachy: care to review the hid battery stuff?
21:33:30	braewoods	or were you waiting for something eles
21:33:32	braewoods	else
21:34:58	speachy	what have you built it on?
21:44:16	speachy	cleanly builds for simulators etc?
21:44:47	braewoods	speachy: just the sansafuzeplus
21:44:59	braewoods	speachy: i don't have anything setup to build so much at once
21:45:06	braewoods	but pretty sure it won't fail to build
21:45:18	braewoods	i gated the HID stuff with the macro used to enable it
21:47:22	braewoods	the rest isn't gated and compiles for the sansafuzeplus just fine
21:47:26	braewoods	so it should work
21:47:33	braewoods	the parts i added to the HID driver anyway
21:47:46	braewoods	i figured powermgmt.c is only one that needed conditional compilation stuff
22:00
22:09:34	braewoods	speachy: adjusted
22:16:13	speachy	hmm. I think every second might be too often.
22:17:04	braewoods	speachy: how often should we send it then?
22:17:35	braewoods	and we should send at least one upon initial connection
22:17:58		Quit ac_laptop (Ping timeout: 245 seconds)
22:18:00	braewoods	so the host has some data and doesn't have to wait for first update
22:18:44	speachy	send the first timeout to be 1s but the subsequent ones can wait every 60s maybe?
22:18:51	braewoods	speachy: how about this then, we don't use ticks, just send updates when battery level change?
22:19:07	braewoods	speachy: well that's the thing, this tries to send regardless of usb connection status so
22:19:30	braewoods	it's fine if done on a timer but the first update should probably be tied to the insertion event
22:19:40	braewoods	if that makes sense
22:19:57	braewoods	we could also makes the updates only sent out if the battery_level has changed
22:19:59	speachy	actually that's better, as long as we send out the first one (relatively) immediately.
22:20:00	braewoods	or a timer
22:20:01	braewoods	instead
22:20:40	speachy	makes sense to update it as the charge changes, yeah. no more than once a minute.
22:21:24	braewoods	i could scale back the current WIP to just have the hid driver changes
22:21:33	braewoods	i could then work on the update process separately
22:22:25	speachy	if (usb_detect() == USB_INSERTED)
22:29:36	speachy	add a function into powermgmt.c along the lines of enable_hid_battery_reporting(timeout) −− it sets the timer to be every N ticks, or 0 disables.
22:30:33	speachy	then in usb_hid_init() call enable_hid_battery_reporting(60), and in usb_hid_disconnect() call enab_hid_Battery_reporting(0)
22:30:33	braewoods	for what purpose? so it can be configured?
22:30:58	speachy	so it's tied to the hid driver, only firing when we have an active hid endpoint
22:31:36	speachy	and next_battery_strength would be initialized to 0.
22:32:11	speachy	and enable_hid_battery_reporting would set the initial timeout to 1 so it fires immediately.
22:32:17	speachy	if any of that makes sense
22:32:21		Join f1reflyylmao [0] (~f1refly@2a01:c22:907d:7a00:56e6:5d8a:23e6:b397)
22:32:51	braewoods	i suppose so, but isn't usb_hid_init the wrong place to do that? that fires even if the driver is not used
22:33:23	speachy	I mean usb_hid_init_connection()
22:33:23	braewoods	see usb_core_init and the comment
22:33:27	braewoods	ok.
22:34:13		Quit f1refly (Ping timeout: 245 seconds)
22:34:14		Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c22:907d:7a00:56e6:5d8a:23e6:b397)
22:35:13	speachy	I think 60s is a reasonable update interval since the battery level doesn't change _that_ quickly... alternatively you could change powermgmt.c to make it only emit upon changes
22:35:52	braewoods	we can also make the frequency configurable at a later date
22:35:55	speachy	actually I like that better; screw the periodic tick. :)
22:36:04	braewoods	ok.
22:36:22	braewoods	i'll still need a way to send them immediately upon first insertion...
22:36:24	braewoods	hm
22:36:40	braewoods	i can do that in powermgmt.c if i monitor usb changes there but still
22:36:46	braewoods	i know what i'll do.
22:36:57	speachy	enable_hid_Battery_reporting(true) will trigger an immediate message
22:37:24	braewoods	yea.
22:37:44	braewoods	in any case
22:37:46	braewoods	back to work on it
22:56:44	braewoods	speachy: implemented
22:59:14	speachy	you can set battery_report_percent to -1 in set_battery_reporting() which will make (battery_report_percent == -1) superfluous. as battery_percent will never == -1
22:59:45	speachy	and the entire else (!battery_reporting) block
23:00
23:00:33	speachy	simplifies the code a bit
23:00:36	braewoods	it'll become a global variable then
23:00:42	braewoods	since i can't do that otherwise
23:01:12	speachy	it's in ram anyway
23:02:39	speachy	oh, move set_battery_Reporting(false) to immediately after the logf()
23:04:26	braewoods	not sure why it matters
23:04:28	braewoods	but ok
23:04:54	speachy	slightly racy −− you could conceivably have the HID start flight after the active=false etc
23:05:36	braewoods	is that a problem? usb_hid_send doesn't send anything if the driver is inactive
23:05:44	speachy	jsut good practice to have the deinit() be the inverse order of your init()
23:06:15	braewoods	but ok
23:06:28	braewoods	so uh
23:06:53	speachy	and I think I'll be done picking on your code
23:07:07	speachy	and beating it up for its lunch money
23:08:46	braewoods	here it goes
23:10:38	braewoods	i removed part of the code since your proposals made it irrelevant
23:10:54	braewoods	i had a boolean set aside to push an update later since my logic was more involved
23:11:01	braewoods	but with it no longer being needed
23:11:06	braewoods	made sense to just merge the branches
23:11:10	speachy	yep
23:11:39	speachy	still works? :D
23:14:38	speachy	good on the x3
23:15:04	fs-bluebot	Build Server message: New build round started. Revision f647cde3c7, 293 builds, 9 clients.
23:15:58	speachy	braewoods: awesome little feature addition
23:17:44	braewoods	speachy: _bilgus wondered if it could be used by rbutils, but... why?
23:18:03	***	Saving seen data "./dancer.seen"
23:18:11	braewoods	making sure there's enough battery to upgrade rockbox?
23:18:17	speachy	report the device status, but I don't think we're able to get that info easily via windows at least.
23:18:29	braewoods	it's easy on linux
23:18:32	braewoods	we can probe /sys
23:18:40	speachy	(or macos, even..)
23:19:15	braewoods	well it would be a way to verify that RB is installed correctly
23:19:18	braewoods	and booting
23:24:06	speachy	it cna check that via the iManufacturer/iModel USB descriptors
23:24:25	speachy	(well, assuming rockbox is _running_ when it's plugged in...)
23:26:49	fs-bluebot	Build Server message: Build round completed after 705 seconds.
23:26:59	fs-bluebot	Build Server message: Revision f647cde3c7 result: All green
23:28:37	braewoods	speachy: so i found a battery with a thermistor for my hdd1630... it's labeled as 510mah, and the spec sheet says the battery current is 450 mah...
23:28:45	braewoods	will there be problems when i charge it?
23:29:02	braewoods	charging current*
23:29:04	speachy	the thermistor is going to be on a separate wire
23:29:10	braewoods	indeed it is
23:29:15	speachy	so it doesn't matter
23:29:21	braewoods	ok..
23:29:36	braewoods	the chip docs says it reduces charging current in response to thermal changes
23:30:09	speachy	if the charger doesn't hook up to the thermistor, then it's moot, unless the battery itself has protection circits
23:30:29		Quit ufdm (Ping timeout: 245 seconds)
23:30:49	speachy	sweet, my FAT-layer realignment code no longer hangs the player outright.
23:31:25	braewoods	speachy: great. i'm going to work on MTP next probably.
23:31:42	braewoods	about time to get serious with that
23:31:53	braewoods	just this seemed an easy thing to get implemented
23:32:01	braewoods	and most players can use it
23:32:07	braewoods	provided they already had HID support
23:37:51	speachy	most of the native targets do.
23:38:28	speachy	anyway, bedtime for the wicked. have a good rest-of-your-day!

Previous day | Next day