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-11

00:00:43braewoodsi may end up in a situation where i only allow file transfers when i know rockbox is idle
00:01:50braewoodsMTP is mainly for file transfer but it would still be nice to be able to do other stuff with it too or even while playing music
00:09:29 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019)
00:12:31 Quit advcomp2019_ (Ping timeout: 256 seconds)
00:14:42 Quit ac_laptop (Ping timeout: 246 seconds)
00:44:07_bilgusbraewoods no clue we do have storage is idle events
00:47:48 Quit pixelma (Read error: Connection reset by peer)
00:47:48 Quit amiconn (Read error: Connection reset by peer)
00:47:57 Join pixelma_ [0] (marianne@rockbox/staff/pixelma)
00:47:57 Join amiconn_ [0] (jens@rockbox/developer/amiconn)
00:47:57 Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma)
00:47:57 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn)
01:00
01:02:13 Quit pixelma (Quit: .)
01:02:13 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
01:05:10 Join amiconn [0] (jens@rockbox/developer/amiconn)
01:05:11 Join pixelma [0] (marianne@rockbox/staff/pixelma)
01:18:09 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
01:20:29***Saving seen data "./dancer.seen"
01:24:21 Quit Rower (Ping timeout: 246 seconds)
02:00
02:03:11 Join bonfire_ [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net)
02:05:18 Quit bonfire (Ping timeout: 260 seconds)
02:26:18 Quit emacsomancer (Ping timeout: 260 seconds)
02:30:04 Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
02:43:47 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
02:43:47 Quit pixelma (Quit: .)
02:44:03 Join amiconn [0] (jens@rockbox/developer/amiconn)
02:44:04 Join pixelma [0] (marianne@rockbox/staff/pixelma)
03:00
03:15:48braewoodsspeachy: how does USB handle data? does it wait to send more until the past data was processed?
03:15:56 Join eevan_ [0] (~eevan@telesto.hot-chilli.net)
03:20:33***Saving seen data "./dancer.seen"
03:57:50 Quit koniu (Ping timeout: 268 seconds)
04:00
04:07:58 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
04:08:57 Quit emacsomancer (Ping timeout: 264 seconds)
04:09:43 Join vmx [0] (~vmx@ip5f5ac61f.dynamic.kabel-deutschland.de)
04:11:21 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
04:15:47 Quit berber (Quit: The Lounge - https://thelounge.chat)
04:16:11 Join berber [0] (~berber@v2202101107577140883.nicesrv.de)
04:22:16 Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
04:33:01 Nick gevaerts_ is now known as gevaerts (~fg@rockbox/developer/gevaerts)
04:42:43 Join eevan57 [0] (5e3b35b3@94.59.53.179)
04:43:50 Quit eevan57 (Client Quit)
04:47:39 Part eevan_
04:48:09 Join eevan [0] (~eevan@telesto.hot-chilli.net)
04:48:32 Nick eevan is now known as Guest39193 (~eevan@telesto.hot-chilli.net)
04:56:09 Part Guest39193
04:58:26speachybraewoods: from rockbox's perspective, the host is control of everything.
04:59:22speachyit's request-driven; host says it's sending or expecting X, set up a transfer to achieve that.
05:00
05:00:12speachyeach given endpoint can only have one open transaction at a time.
05:01:32speachynow if the higher-level protocol allows muxing multiple streams/operations simultaneously, that's up to that layer, but at the "USB" layer, it's "transfer X bytes to/from endpoint Y, block/callback when complete."
05:20:34***Saving seen data "./dancer.seen"
05:23:18 Quit bertrik (Quit: Lost terminal)
05:23:37speachyso an MTP implementation will only interact with the USB stack in three places; the initial descriptor specification (ie defining the endpoints), registering the callback for traffic received on a given endpoint, and sending data to a given endpoint.
05:25:16speachyand on the other side of the MTP implementation, you'll have a pile of hooks into the filesystem code, eg getting directory listings, reading/writing [chunks of] a given file, and perhaps other stuff like deleting.
05:25:58speachythe stuff in the middle doesn't otherwise care about rockbox, beyond standard OS helper functions like malloc/memcmp and so forth.
05:28:10speachyI'd recommend that MTP be treated the same as MSC initially, in that it get exclusive modal access to the disk −− ie playback etc is halted. Otherwise one has to worry about altering stuff that's actively playing, and that's complexity that isn't worth it at this stage.
05:28:57speachy(not to mention the greatly inreased potential for running out of RAM)
05:29:10 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:33:54braewoodsspeachy: i see. ok.
05:35:27braewoodsi'm also planning to investigate the possibility of disabling file access through MTP so the rest of the stateless protocol can still function perhaps
05:35:51braewoodsso it might still be possible to remotely control rockbox
05:35:58braewoodsjust not transfer files
05:36:26braewoodsi don't know, just some ideas i've had
05:36:43braewoodsunless you know of a better USB method for controlling rockbox remotely
05:38:04braewoodsthough to be honest... mtp reminds me a lot of HTTP from reading the spec
05:38:28braewoodsserver (responder) can't send data to the client (initiator) unti the client acts
05:40:01speachythere's always bluetooth's AVRCP!
05:46:05braewoodsspeachy: can you investigate the possibility of enabling the HID driver in charging only mode?
05:46:26braewoodsso it can still report battery levels
05:46:30braewoodsin the background
05:47:36speachysure, that just needs the UI to allow the user to select between mass storage+everything, full HID, HID status only, and charge only.
05:48:23braewoodstruth be told, we can't enable all drivers at all times due to endpoint limitations
05:48:36braewoodsMTP is pretty much going to be on its own
05:48:42braewoodsfor many devices
05:48:48braewoodssince it'll use up all the endpoints for itself
05:48:57braewoodsit requires 3 to be recognized as an MTP device
05:49:05braewoodseven though it only really uses 2
05:49:08braewoodswhat's up with that
05:50:12speachyright now chargeonly means just that, no endpoitns advertised.
05:50:27speachyand the charge state is visible on-screen
05:51:47speachythe HID implementation is all-in, either it's active (and owning the UI) or it's not. charge-status-only requires that to be split up/rejiggered.
05:52:16braewoodsI see.
05:52:26braewoodswell given the design of the HID driver
05:52:29speachyso that's the place to start −− we already have "hid mode" as an option
05:52:41braewoodswe could just enable it and not use the other input reports
05:52:45 Join advcomp2019_ [0] (~advcomp20@65-131-179-208.sxct.qwest.net)
05:52:45 Quit advcomp2019_ (Changing host)
05:52:45 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019)
05:53:00braewoodssince the background reports are sent on demand now by the host
05:53:02speachypatches welcome..
05:53:11speachyit's all possible
05:53:14braewoodsi'll look into it later
05:53:20braewoodsright now got a mor important project
05:53:32braewoodsi would rather review this once we got some more usable drivers
05:53:50braewoodsi'm planning to have two modes of operation for MTP if i can pull this off
05:54:04braewoodsone that mainly allows file transfer, exclusive mode
05:54:15braewoodsand shared mode or so which allows (in theory) remote control
05:54:29braewoodsbut still got code to write
05:55:54 Quit advcomp2019__ (Ping timeout: 245 seconds)
05:56:51braewoodsspeachy: what's the recommended way of unpacking byte packed data? a packed struct? or manually extracting it from the data stream in a regular struct?
05:57:00braewoodsi know packed structs have penalties for alignment.
05:57:41speachypacked structure is preferable, but only works when the struct is a fixed size and known in advance.
05:58:10braewoodsok.
05:58:11speachystructs with variable length elements (especially ones in the middle!) mean you pretty much have to parse it field-by-field
05:58:21braewoodsi rarely use packed structs so i wasn't really sure.
05:58:24braewoodsbut i've seen both methods
05:58:33speachyfor USB etc transfers we can ensure operations are properly aligned (for DMA purposes)
06:00
06:00:17braewoodsi think i'll start with adding MTP support for basic stateless stuff that is viable in any mode of use
06:00:33braewoodsmostly to test that my code is working
06:01:13braewoodsspeachy: does RB already do sufficient buffering in its file IO APIs?
06:01:31braewoodsor will i need one for MTP to buffer the USB data until there's enough to flush to disk?
06:02:17braewoodsMTP has overhead granted but i would like to try to make it efficient if i can
06:20:04speachyI guess that depends on the max size of an individual MTP request.
06:21:11speachythe USB stack won't notify the upper layer that a transfer is complete until the entire operation is finished, so you'll need to buffer that much at a time, both reading and writing.
06:22:05speachybut I'd be surprised if MTP mandated support for transfer sizes over 64K. Heck, I'd be surprised if it mandated even 4K minimums.
06:22:21 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
06:44:33braewoodsspeachy: going by what android does to expose itself as MTP...
06:44:47braewoodsi think i need to add an interface string to rockbox's usb core.
06:45:04braewoodsmost of the libmtp examples use these
06:45:09braewoodsandroid just exposes an MTP string
06:45:27braewoodsseems mandatory to placate libmtp too
06:45:53braewoodsi think i will copy what android does to get hosts to recognize it as MTP
06:46:57speachy"interface string" meaning an USB interface containing endpoints, described in
06:47:03speachy..in the descriptor? :D
06:48:05braewoodsmeaning iInterface isn't set to 0
06:48:14speachyyep.
06:48:30braewoodsin any case
06:48:39braewoodsit's a trivial change
06:48:54braewoodsjust trying to solve our MTP by starting from the foundation
06:49:07speachystart with that patch already in gerrit, seriously..
06:49:07braewoodsi plan to work on basic crapola first and test hat
06:49:20braewoodswhich one?
06:49:20speachyit'll save a ton of boilerplate if nothing else.
06:49:38braewoodsi'm probably already referencing it
06:50:12braewoodsbut i'm gradually implementing this piecemeal to help me learn stuff
06:50:39speachywhoops, I meant flyspray
06:50:40speachyhttps://www.rockbox.org/tracker/task/10764
06:50:55speachyI even rebased it vs master-as-of-sep-2020
06:51:30speachyor, er, no, just squashed everything to make it easier to rebase
06:52:04braewoodsyea, i'm already using that as a reference point
06:52:23braewoodsi just noticed the original author couldn't decide how to expose MTP to the host
06:52:38braewoodsand times have changed; windows vista and such are no longer relevant
06:52:53braewoodsso we can probably copy android's technique for it and call it a day
06:53:25speachy"android's technique" is inherently tied to the patched android linux kernel.
06:53:45braewoodsis it? i thought their MTP was implemented in user space
06:54:08speachyit's exposed via the usbgadget stuff
06:54:37braewoodsindeed but it seems the interface descriptor is done in userspace in any case
06:54:48speachyunder linux's hood, it works out more or less the same way as this patch −− adding stuff into the usb configuration descriptors
06:54:58braewoodsin any case
06:55:21braewoodsi need to decide on how we'll expose MTP's existence and there's only a few ways to do so where libmtp will even notice it
06:55:47speachyhardcode it.
06:56:25braewoodsi know...
06:56:33braewoodsi'll have to, but which set of values?
06:56:37speachyadding in config options and spllicing descriptors on the fly is something you do afer your get the hard stuff done.
06:56:47braewoodsi wasn't planning to do that
06:56:51braewoodslol
06:57:03braewoodsi was planning to find a single static set to use and leave it at that
06:57:17braewoodsassuming that'll even work in reality
06:57:52speachy(and "Vista" might not matter, but Win10 surely does, and most rockbox users are using Windows)
06:58:22braewoodsinteresting, umtp responder uses the PTP method
06:58:51speachy(there's MTP-as-specified, and MTP-as-the-dominant-client-OSes-implement-it)
06:59:09braewoodsi'm probably going to lean towards the right
07:00
07:01:45speachythere's no realistic alternative if you want the code to be useful.
07:02:29speachythat was one of the original reasons why that patch was left fallow
07:02:59braewoodsindeed and which is why i only intend to do a partial implementation initially
07:03:07braewoodsmostly to prototype how it works under Linux and such
07:03:20braewoodssee what compatibility issues i might run into
07:03:42braewoodswell, from what i've gathred from existing responders
07:04:01braewoodsAndroid does this approach. it sets 255, 255, 0 for the typical interface class/ protocol / ...
07:04:04braewoodsfamily
07:04:11braewoodsthe other responders do 6 1 1
07:04:37braewoodsboth set an interface string containing MTP
07:05:19braewoodswhich i believe was missing from the original
07:06:23braewoodsindeed it was
07:08:25 Join eevan_ [0] (~eevan@telesto.hot-chilli.net)
07:08:48 Quit koniu (Remote host closed the connection)
07:09:16 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
07:10:38braewoodshttps://github.com/viveris/uMTP-Responder/issues/16
07:10:39braewoodsinteresting
07:10:55braewoodsbut not too important for RB since the host is the one that is going to do all the updating
07:20:35***Saving seen data "./dancer.seen"
07:22:59 Quit tomato (Quit: Ping timeout (120 seconds))
07:25:22 Part eevan_
07:43:13 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
07:47:11 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c0bc-866c-59bc-4ed4.res6.spectrum.com)
07:50:23speachyit's quite sad how many bluetooth stacks were aquired by qualcomm and eventually kille
08:00
08:02:14 Join _bilgus_ [0] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com)
08:03:40 Join spectrumanalyst [0] (~admin@198.46.152.45)
08:05:19 Join fs-bluebot_ [0] (~fs-bluebo@55d4a316.access.ecotel.net)
08:05:37 Join vmx_ [0] (~vmx@ip5f5ac61f.dynamic.kabel-deutschland.de)
08:05:53 Quit ps-auxw (Disconnected by services)
08:06:01 Join ps-auxw [0] (~arneb@p548d56ce.dip0.t-ipconnect.de)
08:06:17 Join Ckatt [0] (~Ckat@xn--z7x.xn--6frz82g)
08:06:56 Join SovietShaman [0] (quassel@024-217-039-226.res.spectrum.com)
08:07:05 Join Strife89|Home [0] (~quassel@adsl-74-250-153-79.ags.bellsouth.net)
08:07:15 Join gsora_ [0] (~gsora@unaffiliated/gsora)
08:07:27 Join shrizza_ [0] (~shrizza@oki-180-131-209-187.jptransit.net)
08:07:35 Quit spectrum- (Ping timeout: 256 seconds)
08:07:35 Quit gsora (Ping timeout: 256 seconds)
08:07:35 Quit _bilgus (Ping timeout: 256 seconds)
08:07:36 Quit vmx (Ping timeout: 256 seconds)
08:07:36 Quit SovietShaman__ (Ping timeout: 256 seconds)
08:07:36 Quit vup (Ping timeout: 256 seconds)
08:07:36 Quit asabas (Ping timeout: 256 seconds)
08:07:36 Quit Strife89 (Ping timeout: 256 seconds)
08:07:36 Quit fs-bluebot (Ping timeout: 256 seconds)
08:07:36 Quit beencubed (Ping timeout: 256 seconds)
08:07:36 Quit shrizza (Ping timeout: 256 seconds)
08:07:36 Quit Ckat (Ping timeout: 256 seconds)
08:07:37 Join asaba [0] (~asaba@103.113.159.184)
08:07:38 Join beencubed_ [0] (~beencubed@209.131.238.248)
08:07:48 Nick Ckatt is now known as Ckat (~Ckat@xn--z7x.xn--6frz82g)
08:08:09 Join vup [0] (~~~~@46.101.193.235)
08:18:39 Quit tomato (Quit: Ping timeout (120 seconds))
08:18:54 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
08:19:52 Quit Romster (Ping timeout: 276 seconds)
08:38:39 Join mendelmunkis [0] (~mendelmun@ool-43568247.dyn.optonline.net)
08:40:37 Join Romster [0] (~romster@unaffiliated/romster)
08:41:40 Quit ender| (Read error: No route to host)
08:41:46 Join MrZeus_ [0] (~MrZeus@89.238.130.71)
08:43:22 Quit tomato (Quit: Ping timeout (120 seconds))
08:46:13 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3)
08:47:08 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
08:48:52 Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:4978:337a:24bd:4bbc)
08:51:17 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09:00
09:03:32 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
09:12:02 Quit Saijin_Naib (Ping timeout: 264 seconds)
09:20:39***Saving seen data "./dancer.seen"
09:23:44 Quit bonfire_ (Quit: Leaving)
09:31:31 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c0bc-866c-59bc-4ed4.res6.spectrum.com)
10:00
10:00:49 Quit Saijin_Naib (Disconnected by services)
10:00:53 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-f87d-7b09-3f64-97aa.res6.spectrum.com)
10:01:26 Quit vmx_ (Quit: Leaving)
10:10:22 Quit tomato (Quit: Ping timeout (120 seconds))
10:20:40 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
10:27:53 Quit ubervison (Quit: Leaving)
10:33:59 Quit tomato (Quit: Ping timeout (120 seconds))
10:37:31 Quit massiveH (Quit: Leaving)
10:54:10 Quit Huntereb (Quit: See ya!)
10:55:33 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:21e:37ff:fe4e:f43a)
11:00
11:03:23 Quit pamaury (Ping timeout: 265 seconds)
11:20:41***Saving seen data "./dancer.seen"
11:40:07 Join amachronic [0] (5284b902@82.132.185.2)
11:45:11amachroniccan anyone tell me what happens to the volume if you divide a PCM sample by 2, in terms of dB? I am pretty much a noob at this stuff & after some googling, I'm thinking it should only reduce volume by ~0.5 dB, but I'm not sure I'm doing my math right. Thanks.
11:46:49amachronicwhoops, my mistake... I mean ~5 dB
12:00
12:00:26 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
12:41:55 Quit amachronic (Quit: Connection closed)
12:48:27 Quit jdarnley (Ping timeout: 256 seconds)
12:49:19 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be)
12:56:59speachyamiconn: /2 = 3dB, I'd think.
13:00
13:05:25rudi_sYes
13:13:14 Quit Saijin-Naib (Ping timeout: 264 seconds)
13:20:43***Saving seen data "./dancer.seen"
13:34:10 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-f87d-7b09-3f64-97aa.res6.spectrum.com)
13:40:31__builtinamachronic (logs): 10 log(0.5) ~= -3 dB
13:53:31 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
13:57:42amiconnHalving the amplitude means -6 dB
13:58:37amiconnFor power it's 10 * log(), but for amplitude it's 20 * log()
13:59:23amiconn(this is of course in order to match, because power is proportional to amplitude^2
14:00
14:13:44 Quit edhelas_ (Remote host closed the connection)
14:18:21 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
14:28:53fs-bluebot_Build Server message: New build round started. Revision bd507fc7b4, 293 builds, 9 clients.
14:39:56fs-bluebot_Build Server message: Build round completed after 663 seconds.
14:39:59fs-bluebot_Build Server message: Revision bd507fc7b4 result: All green
14:43:50fs-bluebot_Build Server message: New build round started. Revision 043e8a0c5c, 293 builds, 9 clients.
14:44:11 Join amachronic [0] (5284b85f@82.132.184.95)
14:47:20 Join penseur [0] (b2a9ca3b@178-169-202-59.beloslav.ddns.bulsat.com)
14:47:22amachronicamiconn: thanks for the clarification... I was hoping to get rid of SW volume on my M3K port, maybe -6 dB will be just enough.
14:48:32 Quit penseur (Client Quit)
14:56:47fs-bluebot_Build Server message: Build round completed after 778 seconds.
14:56:50fs-bluebot_Build Server message: Revision 043e8a0c5c result: All green
15:00
15:05:38 Quit Rower (Ping timeout: 256 seconds)
15:10:39speachyamachronic: if the codec doesn't have hw volume control, rockbox's sw control works automagically. but IIRC the codec requires 32-bit PCM data input... at least under the linux port.
15:11:19speachyamachronic: honestly you're probably better off just fixing the ak4376 to full-scale 0dB volume and letting rockbox handle the SW control.
15:11:27speachySW volume I mean
15:13:08speachyoh cool it supports 16bpp natively. (yay, janky FiiO linux port..)
15:13:25amachronicspeachy: I'm trying to minimize dependence on the SW volume to reduce power consumption. The native ports also have a different SW volume implementation that's only 16 bits.
15:13:57speachythe SW volume control is a rounding error compared to the decoding overhead
15:14:14speachyindeed, the main argument against it is "rounding error" :D
15:15:18 Join calebccff [0] (~calebconn@connolly.tech)
15:15:19calebccffHey! I've been slowly working on (attemping to..) port Linux to the iPod classic 1G, or 6th gen. Right now I've barely got the kernel booting but it's getting there. As part of that I've added the ability to boot a Linux kernel with a DTB to the rockbox bootloader (for the classic). Would you guys be interested in taking that upstream?
15:15:33calebccffPerhaps not now, but if I manage to get a Linux port in any way usable :>
15:15:34speachyto get the volume control rb users expect, we have to go to a bizzare combo hw/sw model, which largely obliviates the power consumption argument.
15:16:16speachycalebccff: you mean getting the linux stuff upstream, or rockbox-specific changes?
15:16:45calebccffI mean submitting patches to rockbox to make the bootloader capable of booting modern Linux
15:16:54calebccff*iPod classic bootloader
15:17:31speachyhmm. I'm okay with that in principle, but it does seem that it would make the bootloader a lot more complicated.
15:20:02calebccffspeachy: yeah, that's a fair point. It doesn't require much changing of the actual code flow, a new function in rb-loader to load regular files into memory, check for a particular button press and if so then call some load_linux function to load the kernel, dtb and potentially initrd and boot it
15:20:28speachythe ipod bootloaders are effectively unmaintained these days −− we make sure they still compile but that's about it. they haven't seen a new build/release in quite some time.
15:20:44***Saving seen data "./dancer.seen"
15:21:32calebccffI'll see what I come up with. There's definitely some cleanup needing done in the 6g bootloader, and a few other minor changes, I'll prepare a patch series and see what you think :)
15:22:08speachyI'm happy to review patches.. just not in a position to test anything.
15:23:21calebccffah right, np. Thanks
15:24:43 Quit amachronic (Quit: Connection closed)
15:25:03 Join amachronic [0] (5284b85f@82.132.184.95)
15:44:53 Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be)
15:46:45 Quit J_Darnley (Ping timeout: 264 seconds)
15:47:40 Quit amachronic (Quit: Connection closed)
15:58:28 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
16:00
16:09:56 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
16:38:19 Quit lebellium (Quit: Leaving)
17:00
17:20:46***Saving seen data "./dancer.seen"
17:42:23braewoodsi guess i'm weird; i prefer to add new features to the USB stack instead
17:42:32braewoodssince that'll see more general use
18:00
18:05:08 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
18:10:09 Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
18:11:57 Quit Rower (Ping timeout: 264 seconds)
18:23:21 Quit calebccff (Quit: Idle timeout reached: 10800s)
18:49:06 Quit Rower- (Ping timeout: 246 seconds)
18:49:31 Join eevan_ [0] (~eevan@telesto.hot-chilli.net)
18:50:29 Part eevan_
18:59:41 Quit ac_laptop (Quit: WeeChat 3.0)
18:59:57 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
19:00
19:00:28 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
19:06:41 Quit pamaury (Ping timeout: 272 seconds)
19:20:47***Saving seen data "./dancer.seen"
20:00
20:36:33 Quit MrZeus_ (Ping timeout: 264 seconds)
21:00
21:20:08 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
21:20:48***Saving seen data "./dancer.seen"
21:40:45 Quit cockroach (Quit: leaving)
21:41:12 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
22:00
22:00:45mendelmunkiswhy is it so hard to find good headphones?
22:07:03 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-43568247.dyn.optonline.net)
22:24:42 Join f1reflyylmao [0] (~f1refly@dynamic-095-112-012-036.95.112.pool.telefonica.de)
22:27:09 Quit f1refly (Ping timeout: 245 seconds)
22:27:09 Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-095-112-012-036.95.112.pool.telefonica.de)
22:30:10braewoodsmendel_munkis: what defines "good"?
22:31:26mendel_munkisgood point. I do want slightly esoteric headphones.
22:31:49mendel_munkis(behind the neck, on ear with bluetooth and a 3.5mm port)
22:40:03 Quit ac_laptop (Ping timeout: 245 seconds)
23:00
23:04:01 Quit Soap_ (Read error: Connection reset by peer)
23:20:49***Saving seen data "./dancer.seen"

Previous day | Next day