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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2021-03-12

01:00
01:00:39 Join f1reflyylmao [0] (~f1refly@2a01:c23:6015:af00:994d:368e:3a7f:5689)
01:02:42 Quit f1refly (Ping timeout: 260 seconds)
01:02:42 Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c23:6015:af00:994d:368e:3a7f:5689)
01:20:53***Saving seen data "./dancer.seen"
03:00
03:20:56***No seen item changed, no save performed.
04:00
04:10:11braewoodsspeachy: work on mtp will be slow but i have plenty of reference implementations to help me figure out what we'll need to implement
04:21:28 Nick alexbobp_ is now known as alexbobp (~alex@meowface.org)
04:42:38 Join vmx [0] (~vmx@95.90.198.31)
05:00
05:19:22 Quit Stanley00 (Remote host closed the connection)
05:20:58***Saving seen data "./dancer.seen"
05:24:18 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
05:41:04 Join GeekShadow [0] (~antoine@82-64-164-139.subs.proxad.net)
05:41:04 Quit GeekShadow (Changing host)
05:41:04 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow)
05:42:59 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:56:51 Quit Stanley00 (Remote host closed the connection)
05:57:28 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
06:00
06:02:28 Quit Stanley00 (Ping timeout: 276 seconds)
06:03:56 Join MrZeus_ [0] (~MrZeus@89.238.130.71)
06:09:47 Quit pamaury (Ping timeout: 272 seconds)
06:15:49braewoodsspeachy: is it at all possible for the usb core to call the transfer_complete function with a direction that conflicts with the endpoint's registered direction?
06:15:56braewoodsthe code seems to assume this cannot happen
06:16:02braewoodsin the existing drivers
06:16:43braewoodsnot to mention i'm not even sure why it includes that when the direction is supposed to be encoded into the endpoint
06:18:30speachynot unless there is a major bug elsewhere in our usb core. or the hardware is broken.
06:19:14braewoodsis there special meaning to "status" or is it just a boolean?
06:19:15 Quit koniu (Remote host closed the connection)
06:19:37braewoodsit seems treated as a typical zero or non-zero value in C conventions
06:19:42braewoodswhich is effectively boolean
06:19:48 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
06:20:10braewoodsjust trying to better understand the arguments to driver callbacks
06:21:42braewoodsMTP sure is a daunting protocol
06:21:55braewoodsthankfully we don't need to implement all of it
06:23:18braewoodsspeachy: i've got a lot of ideas for our own mtp extensions... i would like to extend rbutil with some useful extras that could use MTP in theory to do some stuff best done from the host.
06:23:33braewoodsone example i thought up, set the RTC clock to current host time
06:24:35braewoodssince RB will never have NTP support
06:24:40braewoodsthis is the next best thing :P
06:28:39speachywith respect to endpoints; direction is encoded into the number. BIT7 means it's a host->device endpoint.
06:28:59braewoodsindeed
06:29:43speachybut that's the number according to the USB protocol, the "endpoint" as rockbox refers to it is the index into our endpoint table, which definitely does not have 8 bits of entries.
06:30:40speachy(usually but not necessarily mapping directly to the hardware "endpoint")
06:32:20speachyI wish I could trust the latest forum for the ipod/iflash saga.
06:32:28speachylatest forum results
06:41:24speachyhowever, another thing did occur to me −− perhaps it's not ata power management at all, but UDMA2.
06:44:48 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
06:46:05braewoodsinteresting, mtp may be all we need to control rockbox from the host
06:46:32braewoodsso i'm probably going to define 3 sets of operation...
06:46:41braewoods1 that's available in all modes
06:46:51braewoods2 stuff only available in storage mode
06:47:01braewoods3 stuff only available in playback or remote control mode
06:47:18braewoodsi also noticed MTP defines a powerdown operation
06:47:24braewoodscould be linked to power shutoff
06:49:13 Quit Stanley00 (Ping timeout: 245 seconds)
07:00
07:07:31speachyand come to think of it, the working theort for the disk corruption (ie due to buggy sleep) doesn't explain corruption in MSC mode, as the disk is always left on there. or should be.
07:17:12 Join Soap [0] (~Soap@rockbox/staff/soap)
07:21:01***Saving seen data "./dancer.seen"
07:21:43speachyokay, I used some rockbox funds to buy an iFlash SD->CF adapter
07:22:17 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
07:31:42 Quit koniu (Remote host closed the connection)
07:32:09 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
07:48:50 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
07:58:34 Join dweeber [0] (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net)
08:00
08:00:50 Quit dweeber` (Ping timeout: 260 seconds)
08:08:34 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
08:09:51 Quit ender| (Quit: Everything we were told about communism was a lie. Unfortunately, everything we were told about capitalism was true.)
08:23:34 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3)
08:35:56braewoodsspeachy: this is kinda weird. i just realized the layout of the basic mtp packets means there's naturally no padding so packed actually has no effect on them
08:40:11 Quit massiveH (Quit: Leaving)
08:43:16 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
08:49:56 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
08:50:04speachyhuh, it actively goes into sleep even in usb mode.
08:54:21 Quit Stanley00 (Ping timeout: 246 seconds)
08:54:36 Quit Saijin_Naib (Read error: Connection reset by peer)
09:00
09:19:15 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-f87d-7b09-3f64-97aa.res6.spectrum.com)
09:21:03***Saving seen data "./dancer.seen"
09:22:44 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
09:23:29 Join calebccff [0] (~calebconn@connolly.tech)
09:23:30calebccffI've added my ssh key to gerrit but I'm getting "permission denied (publickey)" when trying to test it with ssh. I'm able to use keypair auth to ssh to other hosts, and git instances
09:24:55speachyso what does 'ssh -v username@gerrit.rockbox.org -p 29418' show?
09:26:18speachy(your username is shown in the user profile of gerrit)
09:27:08 Quit Stanley00 (Ping timeout: 245 seconds)
09:27:10calebccffspeachy: https://paste.ubuntu.com/p/ssg3zfsb3g/
09:27:45speachy"send_pubkey_test: no mutual signature algorithm"
09:28:10speachyadd 'host gerrit.rockbox.org
09:28:12speachy PubkeyAcceptedKeyTypes ssh-rsa
09:28:14speachyy
09:28:19speachyto your ~/.ssh/config
09:28:50calebccffHuh nice, thanks! I wonder why it was failing on that?
09:29:31speachyopenssh deprecated ssh-rsa, but the embedded ssh server in gerrit still relies on that.
09:29:48speachyupdating gerrit is on my todo list
09:30:00calebccffAh right, cheers
09:30:24calebccffNice, patch is pushed!
09:31:37speachyI can't seem to figure out what STG_EVENT_ASSERT_ACTIVE() actually does. As in it seems to have no meaningful effect on anything.
09:36:47 Quit Natch (Remote host closed the connection)
09:42:07 Join Natch [0] (~Natch@c-b471e255.014-297-73746f25.bbcust.telenor.se)
09:51:15fs-bluebot_Build Server message: New build round started. Revision 04c29984ce, 293 builds, 9 clients.
09:51:28speachycalebccff: congratulations on your first code commit
09:52:19calebccffwoohoo :D
09:54:49 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
09:59:32 Quit Stanley00 (Ping timeout: 256 seconds)
10:00
10:03:38fs-bluebot_Build Server message: Build round completed after 742 seconds.
10:03:39fs-bluebot_Build Server message: Revision 04c29984ce result: All green
10:05:57fs-bluebot_Build Server message: New build round started. Revision 2743bde09b, 293 builds, 9 clients.
10:06:12speachyokay, this build will bump the poweroff delay to 5s when ATA SLEEP isn't supported
10:10:27 Quit pamaury (Ping timeout: 272 seconds)
10:14:47calebccffspeachy: does rockbox support sending printf over serial? I thought it did, played about with some config settings but didn't get anything until I added this: https://github.com/ipodclassic-mainline/rockbox/commit/7405e5307ecccc81a17ad059ce0e6632a80f8224
10:15:24speachycalebccff: it does in theory, though it's obviously bitrotten.
10:16:30calebccffhaha, right, my hacky patch will conflict with iAP I'd assume? Although I never saw messages when booted into rockbox, other than the string of bytes from iAP
10:16:49speachyIIRC it's reliant upon target-specific hooks being present/enabled.
10:16:56calebccffAh right
10:17:24fs-bluebot_Build Server message: Build round completed after 687 seconds.
10:17:26fs-bluebot_Build Server message: Revision 2743bde09b result: All green
10:33:42 Quit _bilgus_ (Read error: Connection reset by peer)
10:34:47 Join _bilgus_ [0] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com)
10:38:05 Quit vmx (Ping timeout: 256 seconds)
11:00
11:03:09 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
11:07:32 Quit Stanley00 (Ping timeout: 256 seconds)
11:12:43 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
11:17:08 Quit Stanley00 (Ping timeout: 245 seconds)
11:21:05***Saving seen data "./dancer.seen"
11:35:57 Quit jdarnley (Ping timeout: 264 seconds)
11:37:46 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
11:49:31 Join vmx [0] (~vmx@ip5f5ac61f.dynamic.kabel-deutschland.de)
11:50:00 Quit vmx (Remote host closed the connection)
12:00
12:06:06 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
12:14:26 Quit Saijin_Naib (Ping timeout: 264 seconds)
12:30:10 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-0d0b-e35a-1d62-4480.res6.spectrum.com)
12:54:45 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
13:00
13:13:13 Quit cockroach (Quit: leaving)
13:21:06***Saving seen data "./dancer.seen"
13:28:03 Quit pamaury (Ping timeout: 272 seconds)
13:29:56 Quit calebccff (Quit: Idle timeout reached: 10800s)
13:32:00 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
13:36:24 Quit beencubed_ (Quit: Leaving)
13:40:16 Join beencubed [0] (~beencubed@209.131.238.248)
13:49:14 Quit Saijin_Naib (Ping timeout: 264 seconds)
14:00
14:00:10 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-b4aa-adf0-99f5-c1cf.res6.spectrum.com)
14:06:03 Quit pamaury (Ping timeout: 272 seconds)
14:07:25 Join eevan_ [0] (~eevan@telesto.hot-chilli.net)
14:07:27 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
14:13:33 Quit Galois (Ping timeout: 260 seconds)
14:15:57 Join lebellium_ [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
14:19:17 Part eevan_
14:19:45 Quit lebellium (Ping timeout: 264 seconds)
14:37:03 Join Galois [0] (djao@efnet.math.uwaterloo.ca)
15:00
15:02:19 Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be)
15:02:33 Quit J_Darnley (Ping timeout: 245 seconds)
15:21:07***Saving seen data "./dancer.seen"
15:34:39 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
15:39:01 Quit Strife89|Home (Quit: No Ping reply in 180 seconds.)
15:40:42 Join Strife89 [0] (~quassel@adsl-74-250-153-79.ags.bellsouth.net)
15:58:16 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox)
15:59:24 Quit thomasjfox (Client Quit)
16:00
16:06:44 Quit Rower (Ping timeout: 256 seconds)
16:09:35 Quit Strife89 (Quit: No Ping reply in 180 seconds.)
16:11:10 Join Strife89 [0] (~quassel@adsl-74-250-153-79.ags.bellsouth.net)
16:13:01 Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257)
16:22:51 Quit pamaury (Ping timeout: 272 seconds)
16:31:45 Quit Strife89 (Quit: No Ping reply in 180 seconds.)
16:32:24 Join Strife89 [0] (~quassel@adsl-74-250-153-79.ags.bellsouth.net)
16:44:43 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
16:48:21 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
16:48:49 Quit jdarnley (Ping timeout: 245 seconds)
16:49:25 Quit Strife89 (Quit: No Ping reply in 180 seconds.)
16:51:14 Join Strife89 [0] (~quassel@adsl-74-250-153-79.ags.bellsouth.net)
17:00
17:21:10***Saving seen data "./dancer.seen"
17:21:26 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
17:51:00 Quit ac_laptop (Ping timeout: 256 seconds)
18:00
18:22:20 Quit lebellium_ (Quit: Leaving)
18:25:35 Join Strife89|Home [0] (~quassel@adsl-74-250-141-178.ags.bellsouth.net)
18:27:39 Quit Strife89 (Ping timeout: 246 seconds)
18:37:07 Quit pamaury (Ping timeout: 272 seconds)
18:50:45 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
19:00
19:21:11***Saving seen data "./dancer.seen"
19:29:24 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
19:35:50 Quit ac_laptop (Ping timeout: 256 seconds)
19:42:08 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
19:44:51 Join bonfire [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net)
19:51:41braewoodsspeachy: should we implement the responder data phase optimization? the spec says the responder can either choose to always include the data packet header for each payload unit or only on the first
19:51:55braewoodsso it will be a continuous stream after the first header
19:52:09braewoodsit's ultimately more efficient
19:52:26speachyIMO whatever is simpler to implement
19:52:28braewoodsless processing overhead for large transfers and the data can just be written to disk
19:52:30speachy(and thus, get working)
19:52:42speachycan always optimize it later.
19:52:49braewoodsthis is what uMTP does
19:53:00braewoodsspec even says it's up to the initiator to figure out what mode the responder is using
19:53:16braewoodsthe responder's only obligation is to do it consistently
19:53:34braewoodsit would probably be easier to go this route
19:53:50braewoodsspeachy: i'm also going to ignore the considerations for files > 4GB or so
19:54:02braewoodssince RB can't use files that large anyway thanks to fat32 limits
19:55:04braewoodsso can't see any value in supporting operations that large
19:55:29braewoodseven if i wanted to and had enough storage space, the per file limit doesn't support it afaik
19:56:27braewoodscan't see anyone needing to transfer data that large anyway
19:56:52braewoodsmost individual audio files will be less than 1GB
20:00
20:08:30 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
20:43:14 Quit Saijin_Naib (Ping timeout: 264 seconds)
20:50:49 Quit koniu (Remote host closed the connection)
20:51:28 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
20:52:46 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-54b4-96e8-240f-2146.res6.spectrum.com)
21:00
21:21:15***Saving seen data "./dancer.seen"
21:27:02 Quit Saijin_Naib (Ping timeout: 264 seconds)
22:00
22:28:04 Quit cockroach (Quit: leaving)
22:31:21 Join f1reflyylmao [0] (~f1refly@dynamic-095-116-139-234.95.116.pool.telefonica.de)
22:31:42 Quit f1refly (Ping timeout: 260 seconds)
22:31:43 Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-095-116-139-234.95.116.pool.telefonica.de)
23:00
23:21:16***Saving seen data "./dancer.seen"
23:33:17 Quit koniu (Remote host closed the connection)
23:33:51 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
23:51:44 Quit koniu (Remote host closed the connection)
23:52:14 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)

Previous day | Next day