| 00:14:04 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 00:14:04 | | Quit pixelma (Quit: .) |
| 00:14:57 | | Join pixelma [0] (marianne@p4fe76649.dip0.t-ipconnect.de) |
| 00:14:57 | | Join amiconn [0] (jens@p4fe76649.dip0.t-ipconnect.de) |
| 00:42:34 | *** | Saving seen data "./dancer.seen" |
| 00:58:26 | | Quit Galois (Remote host closed the connection) |
| 01:00 |
| 01:26:00 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 01:46:45 | | Quit mrkrisprolls (Remote host closed the connection) |
| 02:00 |
| 02:42:36 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:24:08 | | Quit tobbez (Ping timeout: 245 seconds) |
| 03:31:06 | | Join tobbez [0] (tobbez@user/meow/tobbez) |
| 03:33:35 | | Join martylake [0] (~martylake@82.66.174.242) |
| 04:00 |
| 04:06:30 | | Quit tobbez (Ping timeout: 260 seconds) |
| 04:07:00 | | Join mrkrisprolls [0] (~mrkrispro@lecturify.net) |
| 04:08:35 | | Join ac_laptop [0] (~ac_laptop@2a0c:e303:0:7300:e29d:31ff:fe2d:a258) |
| 04:08:48 | ac_laptop | hello people |
| 04:09:00 | CH23 | hello, ac_laptop |
| 04:09:58 | ac_laptop | I've tried to upgrade rockbox on my xduo x3ii from rbutil and I coudn't reboot it after that |
| 04:10:28 | ac_laptop | Selecting the player in the bootload results in a black screen of a few seconds and then a reboot |
| 04:11:00 | CH23 | will it still mount on your computer? |
| 04:11:10 | ac_laptop | CH23: no |
| 04:11:47 | ac_laptop | I've rebooted on the stock firmware and tried to reinstall from there but it says the mSD is read-only |
| 04:12:31 | ac_laptop | should I attempt to reinstall by hand ? |
| 04:13:10 | | Join tobbez [0] (tobbez@user/meow/tobbez) |
| 04:19:56 | ac_laptop | brb |
| 04:19:58 | | Quit ac_laptop (Quit: WeeChat 3.8) |
| 04:20:12 | CH23 | i wonder if your µSD card has broken and went into read-only mode. |
| 04:27:43 | | Join ac_laptop [0] (~ac_laptop@2a0c:e303:0:7300:e29d:31ff:fe2d:a258) |
| 04:31:30 | CH23 | ac_laptop: i wonder if your µSD card is broken. is it writable from the computer when input directly? |
| 04:32:28 | ac_laptop | CH23: yes, I've actually cleaned up some space this way |
| 04:32:46 | ac_laptop | and now it boots on Rockbox but still says it's not writeable |
| 04:35:16 | CH23 | that's weird. not sure why or how that could happen. |
| 04:36:00 | ac_laptop | maybe there was something wrong with last install (not enough space, not unpacking properly ?) |
| 04:37:30 | CH23 | rockbox usually doesn't take that much space, probably less than 50MB or so, even with all games and stuff included |
| 04:41:56 | ac_laptop | I'll install last daily build manually |
| 04:42:38 | *** | Saving seen data "./dancer.seen" |
| 04:45:26 | ac_laptop | now my card appears read-only even when mounted directly |
| 04:45:35 | ac_laptop | looks like something is wrong indeed |
| 04:46:05 | CH23 | how old is the sd card? |
| 04:46:15 | CH23 | also brand/size |
| 04:47:34 | Trzyzet | from my experience, if official SD card formatter from sdcard.org doesn't work then card is dead. |
| 04:52:46 | ac_laptop | CH23: samsung EVO mSDHC 32G, bought it in 2016 |
| 04:57:13 | CH23 | ac_laptop you could try the tool Trzyzet mentions, be aware that it can erase all data on the card if you do. seeing as it's 8 years old, i find it likely that it's just broken though |
| 05:00 |
| 05:02:05 | ac_laptop | CH23: yes, rockbox was very slow on some operations recently, it could be that the card has reached end of life |
| 05:02:38 | ac_laptop | CH23: does rockbox do a lot of rw when it's installed on the card ? |
| 05:03:43 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 05:07:55 | CH23 | i'm not entirely sure. I thought it didn't |
| 05:08:48 | | Quit OlsroFR (Quit: Client closed) |
| 05:20:23 | ac_laptop | CH23: well I did an fsck -a and it seems to work now, I could mount in rw and reinstall rockbox |
| 05:27:49 | CH23 | Nice |
| 05:36:08 | | Quit PheralSparky (Read error: Connection reset by peer) |
| 05:53:29 | | Join braewoods__ [0] (~braewoods@user/braewoods) |
| 05:54:56 | | Join lunchd [0] (~launchd@bitbot/husky/launchd) |
| 06:00 |
| 06:01:06 | spork | do not count on it to live forever though |
| 06:02:19 | | Quit mrkrisprolls (*.net *.split) |
| 06:02:20 | | Quit paulk (*.net *.split) |
| 06:02:20 | | Quit LjL (*.net *.split) |
| 06:02:20 | | Quit launchd (*.net *.split) |
| 06:02:21 | | Quit braewoods_ (*.net *.split) |
| 06:02:21 | | Quit Nezumi-sama (*.net *.split) |
| 06:05:28 | | Join mrkrisprolls [0] (~mrkrispro@lecturify.net) |
| 06:05:28 | | Join paulk [0] (~paulk@about/aquilenet/user/paulk) |
| 06:05:28 | | Join LjL [0] (~ljl@user/ljl) |
| 06:05:28 | | Join Nezumi-sama [0] (~narf@syn-067-053-148-069.biz.spectrum.com) |
| 06:08:05 | ac_laptop | spork: well it's time to buy some spare of course, but given that I very rarely upgrade the contents on this card (change the music libary, upgrade rockbox), an sd card on rockbox should last fairly long |
| 06:08:51 | ac_laptop | it's not like a camera which does write operations on each capture |
| 06:42:41 | *** | Saving seen data "./dancer.seen" |
| 06:44:58 | | Quit COMPL_EXE (Ping timeout: 245 seconds) |
| 08:00 |
| 08:42:43 | *** | Saving seen data "./dancer.seen" |
| 08:51:11 | | Quit ac_laptop (Quit: WeeChat 3.8) |
| 09:00 |
| 09:30:58 | speachy | at minimum you'll have a write on every shutdown. |
| 09:31:14 | speachy | but flash will deteriorate over time, even for read-only loads. |
| 09:41:35 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 09:41:54 | OlsroFR | Benchmarked my iPod Mini with a 128GB SD Card + Red CF to SD adapter: also around only 6 hours of battery life |
| 09:42:44 | OlsroFR | so using the Red CF Adapter lead to the same result as using an official iFlash one (even though they claim that the Red CF Adapter supports TrueIDE mode) |
| 09:43:29 | OlsroFR | I don't know about other iPod models since the IDE_power_enable does something different based on the model of the iPod, but it really looks like it does nothing concrete on the iPod Minis 2nd gen |
| 09:44:37 | OlsroFR | with a real HDD or compact flash, the battery life is good probably just because these devices listens to the ATA command that is sent before attempting to cut down the power which lead to the same result |
| 09:45:41 | speachy | ide_power_enable() toggles a GPIO and another register on the mini2g. |
| 09:46:19 | speachy | but I do see a distinct current drop when the drive is powered down according to my meter. |
| 09:47:14 | OlsroFR | yup. I looked into the iPodLinux project and I searched on Google to see if someone documented it and unfortunately power management is documented only for the first ipods so I couldn't try to change things to debug |
| 09:47:43 | OlsroFR | maybe also that GPIO does its thing only if the drive supports something related to power management |
| 09:47:54 | speachy | no |
| 09:48:09 | OlsroFR | it's kinda cursed that the difference to get a difference of 10 hours in battery life only when I use an iFlash/SD adapter |
| 09:48:20 | speachy | my supposition is that that GPIO controls a power regulator. |
| 09:48:39 | OlsroFR | according to tarkan's benchmarks, using an SD card should lead to something like -20% of battery life maximum compared to a CF card |
| 09:49:28 | speachy | you need to be measuring current to make useful (granular) observations. |
| 09:49:42 | OlsroFR | also, the fact that I can't notice a difference (even just one more hour ?) between cutting down power or not, is worrying |
| 09:50:29 | OlsroFR | your patch had no noticeable impact on both of my setups (Red CF Adapter or iFlash). |
| 09:50:37 | speachy | so it's possible/likely that something else is necessary. but that will probably require pcb-level analysis. |
| 09:51:04 | OlsroFR | But if I use the iFlash adapter on Stock OS, it lasts twice longer (I will do a benchmark soon to compare) |
| 09:51:05 | speachy | or re-reverse-engineering the original firmware |
| 09:51:26 | OlsroFR | So you know any meaningful tool that I can use to reverse-engineer the original firmware ? |
| 09:52:14 | OlsroFR | Do* |
| 09:52:22 | speachy | IDA pro, ghidra? |
| 09:52:34 | speachy | it's not a matter of "tools" but rather skill and persistence. |
| 09:52:50 | speachy | the folks who did the original work back the day have long since moved on |
| 09:55:37 | OlsroFR | I am very motivated at continuing searching on this as much as I can; the mini is an awesome pod |
| 09:56:30 | OlsroFR | An SD modding is much more convenient to do rather than CF modding when you want to deal with high capacities. Also, CF cards are limited to 256GB, even high-end ones |
| 09:57:44 | speachy | since we already know a lot about the mini2g, could probably start by finding where apple twiddles the DEV_IDE0 bit of the DEV_EN register, and see what else is going on around it. |
| 10:00 |
| 10:02:58 | OlsroFR | I just started to benchmark the battery on Stock OS just to be sure since I did it long time ago |
| 10:03:13 | speachy | playing the exact same files? |
| 10:03:14 | OlsroFR | same songs, same codec (AAC 160kbps CVBR) |
| 10:03:59 | speachy | another thing to consider is relative efficiency of the codecs. |
| 10:04:00 | OlsroFR | order seems to be different but I don't think it will matter significantly since it's more than 600 different songs |
| 10:04:22 | OlsroFR | I already did benchmarks between AAC and Musepack (MPC) and the difference was very small |
| 10:04:58 | OlsroFR | < than 1 hour runtime difference |
| 10:05:35 | speachy | mpc and aac are both pretty cpu intensive |
| 10:05:36 | OlsroFR | Maybe the difference is more significant if using something like OPUS that is stressing hard the CPU, but AAC is decoded pretty efficiently by Rockbox |
| 10:05:51 | speachy | compared to eg mp3 |
| 10:06:25 | speachy | don't know what kind of dynamic clocking the apple firmware does |
| 10:06:31 | speachy | (if any) |
| 10:07:01 | OlsroFR | https://www.rockbox.org/wiki/CodecPerformanceComparison most of the time, mpc compete pretty well with mp3 in terms of decoding speed, while AAC is a bit heavier |
| 10:07:39 | OlsroFR | but playing the same files, my blue iPod Mini CF modded with a real CF card can last easily around 15 hours backlight off with an equivalent cameron sino battery |
| 10:08:15 | OlsroFR | the only difference is about storage type; real cf card VS sd to cf adapter |
| 10:09:42 | OlsroFR | so even if CPU clock can be optimized further (I don't know), I don't think it will provide a significant boost in terms of battery life. Something unknown is currently plaguing hard the battery life consumption only when these are flash modded with a SD card. |
| 10:11:00 | OlsroFR | apple themselves marketed the 2nd gen ipod minis to last around 18 hours: https://support.apple.com/en-us/112317 so dying in only 5 or 6 hours with cameron sino batteries (which are the best replacements which lasts just as much as an original "new" battery is completely abnormal |
| 10:11:20 | OlsroFR | I hope we will ever be able to understand why |
| 10:12:18 | speachy | again this will most likely require tracing the PCB to find where the power supply to the CF connector runs. |
| 10:12:44 | OlsroFR | I can't do this but I will try the Ghidra route |
| 10:12:45 | speachy | there's probably a dedicated switched LDO directly connected to the battery |
| 10:13:06 | OlsroFR | to reverse engineer the Stock OS enough to understand what register it may set |
| 10:13:14 | speachy | find where that control signal goes |
| 10:26:29 | _bilgus_ | ^ something similar increased battery life on the sansav1 devices by ~1hr https://gerrit.rockbox.org/r/c/rockbox/+/1887 |
| 10:27:18 | _bilgus_ | but thats a dedicated chip and an actual datasheet to help find it |
| 10:29:18 | OlsroFR | Ghidra cannot do analysis on the binary: (These messages are also written to the application log file) |
| 10:29:19 | OlsroFR | Demangler GNU> Unable to demangle symbol: Reset at 00000000. Message: null |
| 10:29:19 | OlsroFR | Demangler GNU> Unable to demangle symbol: UndefinedInstruction at 00000004. Message: null |
| 10:29:20 | DBUG | Enqueued KICK OlsroFR |
| 10:29:20 | OlsroFR | Demangler GNU> Unable to demangle symbol: SupervisorCall at 00000008. Message: null |
| 10:29:20 | OlsroFR | Demangler GNU> Unable to demangle symbol: PrefetchAbort at 0000000c. Message: null |
| 10:29:21 | *** | Alert Mode level 1 |
| 10:29:21 | OlsroFR | Demangler GNU> Unable to demangle symbol: DataAbort at 00000010. Message: null |
| 10:29:21 | *** | Alert Mode level 2 |
| 10:29:21 | OlsroFR | Demangler GNU> Unable to demangle symbol: NotUsed at 00000014. Message: null |
| 10:29:22 | *** | Alert Mode level 3 |
| 10:29:22 | OlsroFR | Demangler GNU> Unable to demangle symbol: IRQ at 00000018. Message: null |
| 10:29:22 | *** | Alert Mode level 4 |
| 10:29:22 | OlsroFR | Demangler GNU> Unable to demangle symbol: FIQ at 0000001c. Message: null |
| 10:29:33 | OlsroFR | maybe the firmware is encrypted ? |
| 10:30:21 | speachy | I don't know. |
| 10:30:42 | speachy | if you're looking at the file downloaded from apple, that's not the raw binary either. |
| 10:30:56 | OlsroFR | I extracted the ipsw (which is a zip) |
| 10:30:58 | speachy | welcome to the wonderful world of reverse engineering |
| 10:31:29 | speachy | I mean the "Firmware update binary" itself is usualyl some sort of wrapper around the raw binary. eg including a header with length, checksums, etc. |
| 10:39:23 | *** | Alert Mode OFF |
| 10:42:46 | *** | Saving seen data "./dancer.seen" |
| 10:57:52 | OlsroFR | well I don't have the knowledge to go further, Ghidra is too messy and can't find online doc outside of the Rockbox project itself |
| 11:00 |
| 11:55:45 | speachy | the ipod4linux source code repo doesn't cover the power control of the ide controller, on any target. |
| 11:57:38 | | Quit OlsroFR (Quit: Client closed) |
| 12:00 |
| 12:42:48 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:00:57 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 14:01:26 | dconrad | speachy: I'm back in town for the day today, thought I would build the hw4 bootloader and make an update file. It's here: https://drive.google.com/file/d/1i_1W4mUiXSnxn4Oh9pWCnZH9UvHsCPBx/view?usp=sharing |
| 14:01:47 | dconrad | tested out on my device, installs as expected via the stock updater |
| 14:02:18 | dconrad | I also saw the forum post about the old bootloader, I think this patchset should solve that issue: g#6108 |
| 14:02:21 | rb-bluebot | Gerrit review #6108 at https://gerrit.rockbox.org/r/c/rockbox/+/6108 : erosqnative: Check for invalid device_data, default to 1 by Dana Conrad |
| 14:17:14 | speachy | are hw1/hw2 fully runtime detectable? I'd hate to have that fallback cause silent issues. |
| 14:18:45 | dconrad | any newer bootloader should have the hardware version baked in via device_data, even the hw1/hw2 bootloader |
| 14:19:41 | dconrad | I suppose we could even determine hw1 or hw2 based on if device_data is hw1 and we detect the i2c dac, we know we have hw2... but I didn't go that far |
| 14:19:51 | dconrad | perhaps I should? |
| 14:20:12 | speachy | that's what I'm getting at; right now it's a clear "you need to update your bootloader" failure |
| 14:21:00 | dconrad | ah, you'd rather this failure mode? |
| 14:21:10 | dconrad | I can certainly leave it if you want |
| 14:21:36 | speachy | I think that's better than a silent (hah!) failure |
| 14:22:10 | dconrad | fair enough, I'll put a blurb in the troubleshooting document about it |
| 14:22:41 | speachy | but presumably we can detect detect the difference in dac at runtime (ie the only meaningful hw1/hw2 change) |
| 14:22:53 | dconrad | yeah, that was at runtime |
| 14:23:00 | speachy | "was" ? |
| 14:23:06 | dconrad | is |
| 14:23:29 | dconrad | I just meant that was the first hardware change I needed to do detection for haha |
| 14:23:49 | dconrad | it just pings it on i2c and sees if it gets an expected value back |
| 14:23:59 | speachy | so... if the invalid bootdata gets demoted/defaulted to hw1, we still probe for the dac |
| 14:24:04 | dconrad | yep |
| 14:24:15 | speachy | if that probe is successful, we should update the bootdata so teh correct debug info is shown |
| 14:24:15 | dconrad | it's fully independent |
| 14:24:51 | speachy | (ie so the wrong value is never displayed) |
| 14:25:56 | speachy | would be nice to have the debug info be able to show that we did that though. on the hosted side I headed off a lot of bug reports by having the bootloader report its version, and the main firmware displaying that. |
| 14:28:35 | dconrad | well... in literal terms it says "LCD Version:" in the device data debug page, and if you go to the HW Info/Audio page, it'll either say "ES9018K2M HWVOL" OR "SWVOL" |
| 14:29:03 | speachy | hmm, not technically correct any more |
| 14:29:11 | dconrad | yeah... |
| 14:31:26 | dconrad | I think what I can probably do is if it's a hw1 device from device_data, update that to hw2 if the newer dac is found and it should show that way in the device data debug page |
| 14:31:54 | dconrad | and change references to device_data.lcd_version to device_data.hw_version, and verbiage on the debug page |
| 14:32:50 | dconrad | though that still changes the device_data out from under us during runtime like the patchset that's up there now |
| 14:33:18 | dconrad | maybe that's ok? |
| 14:34:22 | speachy | either not at all, or do it right. :D |
| 14:34:39 | speachy | is there a bootdata version field? |
| 14:35:45 | dconrad | doesn't look like it, but we have 3 bytes of unused data |
| 14:39:10 | dconrad | with my understanding of how it works, I don't think there's a way to dynamically change the device_data payload based on the results of an i2c test to the dac though |
| 14:39:40 | dconrad | we would need to have separate bootloaders for hw1 and hw2, which I could see an argument for for consistency I suppose |
| 14:41:22 | dconrad | either way I'm not going to be able to make it happen today so we can mull it over and see how we want to report it in the debug menu I gues |
| 14:42:50 | *** | No seen item changed, no save performed. |
| 14:47:37 | _bilgus_ | sure you can change the payload you have the address |
| 14:49:05 | dconrad | can you? I thought it was hardcoded |
| 14:49:20 | _bilgus_ | our bin gets copied to ram |
| 14:50:16 | dconrad | hmm... I'd have to power up the dac and do the check much earlier than it currently gets done but yeah maybe I could get it to work |
| 14:50:28 | _bilgus_ | the address of the payload points to that address in ram so yeah.. |
| 14:51:04 | _bilgus_ | you could also add a second field and do the same if taht would make it easier to determine v1 v v2 |
| 14:52:49 | | Quit dconrad (Remote host closed the connection) |
| 14:53:23 | _bilgus_ | yeah none of it is even marked read only so you won't even have to do any casts |
| 14:53:47 | _bilgus_ | ahem const sorry |
| 14:54:07 | _bilgus_ | if we were running flash OTOH |
| 14:56:54 | _bilgus_ | you could also wipe the crc to make it fallback in the older bootloader too |
| 14:58:19 | speachy | dconrad: Uh, your patch changes device_data->lcd_version at runtime..? |
| 15:00 |
| 15:00:03 | speachy | yeah, if we were XIP out of flash, that would be different. |
| 15:32:54 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 15:37:09 | | Quit dconrad (Ping timeout: 248 seconds) |
| 15:55:56 | rb-bluebot | Build Server message: New build round started. Revision 5954a2fd48, 345 builds, 9 clients. |
| 15:55:56 | rb-bluebot | runtime info add type to clear time dialog switch to simple_list by William Wilgus |
| 15:58:17 | speachy | dconrad: bootloader uploaded. |
| 16:00 |
| 16:00:01 | speachy | wiki page updated too. |
| 16:05:13 | | Join COMPL_EXE [0] (~compl.exe@aosc/dev/origincode) |
| 16:08:08 | rb-bluebot | Build Server message: Build round completed after 733 seconds. |
| 16:08:10 | rb-bluebot | Build Server message: Revision 5954a2fd48 result: All green |
| 16:08:12 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 16:08:33 | dconrad | I guess I meant I wasn't sure that I could change it at runtime, in the bootloader |
| 16:09:17 | speachy | I think the intent for bootdata is for the bootloader to pass possibly runtime-derived info to the main application, it has to be passed via RAM. |
| 16:11:25 | dconrad | thanks for updating that wiki page too |
| 16:12:04 | _bilgus_ | while the bootloader still has control you are good for whatever after you pass control to the firmware you could change it then too just no longer from the bootloader |
| 16:13:56 | dconrad | I'll go ahead and remove the "we don't have hw4 support yet" todo from the bottom of that page |
| 16:14:07 | _bilgus_ | and ofc you might need to take in to account init stuff that depends on the value |
| 16:17:21 | dconrad | right |
| 16:18:07 | dconrad | I would also like to do it in such a way as to not break it for anyone with a hw2 unit with an older bootloader |
| 16:18:50 | dconrad | if we suddenly do the dac check within the bootloader, it's going to fall back to swvol when they update, if they don't know they need a newer bootloader |
| 16:19:14 | dconrad | unless we check the dac twice |
| 16:21:09 | speachy | this _is_ the time to do breaking bootloader changes fwiw. :D |
| 16:21:30 | speachy | once we hit "stable" on this thing (ie there's an actual release) we're a little more constrained |
| 16:21:39 | dconrad | I suppose that's true |
| 16:21:47 | dconrad | and what the mailing list/forum thread is for |
| 16:22:09 | speachy | I mean all else being equal its' better to not do breaking changes, but there is a compelling technical reason here. |
| 16:24:19 | speachy | in this case I don't know that it matters though. no real harm in doing that hw1/hw2 in the main firmware. |
| 16:24:57 | speachy | your call ultimately, I just think we should have the (to be renamed) 'lcd_version' field accurately show what we know. |
| 16:25:17 | dconrad | yeah that's fair, and is purely mechanical anyway |
| 16:26:01 | dconrad | I'm waffling on it now, I'll see what I can do in a couple days though |
| 16:26:26 | dconrad | it would be nice for it to be simple and concise "here is the definitive hardware version variable" |
| 16:26:26 | speachy | no rush. I'm just glad the ipod6g storage insantiy seems to have stabilized. |
| 16:26:36 | dconrad | congrats, btw |
| 16:26:45 | dconrad | (as I knock on every available wood surface) |
| 16:27:25 | dconrad | did that also resolve other ipod storage corruption issues? |
| 16:27:32 | dconrad | or we don't know yet |
| 16:31:18 | speachy | there are none that I know about |
| 16:31:31 | speachy | (that aren't due to flaky cabling/crappy sd cards) |
| 16:40:37 | | Join Everything [0] (~Everythin@46.211.105.44) |
| 16:41:09 | | Quit dconrad () |
| 16:42:53 | *** | Saving seen data "./dancer.seen" |
| 16:48:07 | speachy | dconrad: I guess we'd also need a hw4 rbutil update |
| 16:49:25 | speachy | _bilgus_: on an unrelated note, I don't know if you still use the X3 on a semi regular basis, but a bootloader update does file off a bunch of the more annoying warts. Notably including being able to boot off of either SD card slot. |
| 17:00 |
| 17:01:29 | _bilgus_ | I really don't except to test stuff I like the thing its just not a great pocket item for someone that breaks anything attached to their person not that I didn't carry around a fuze+ for a while |
| 17:04:20 | speachy | my x3 has been run over more than once at this point |
| 17:04:37 | speachy | it's easily the hardiest device I've ever owned |
| 17:05:32 | _bilgus_ | yeah that aluminum case in nice |
| 17:05:37 | _bilgus_ | is* |
| 17:15:25 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 17:15:48 | dconrad | I swear there's some magic hardware for headphone detection we don't know about https://forums.rockbox.org/index.php/topic,55127.msg254771/topicseen.html#msg254771 |
| 17:16:02 | dconrad | like... it works perfectly fine for me? |
| 17:51:31 | | Quit dconrad () |
| 18:00 |
| 18:39:21 | | Quit speachy (Quit: WeeChat 4.4.3) |
| 18:42:54 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:11:31 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 19:12:11 | OlsroFR | The 2nd gen iFlash Modded iPod Mini that is battery benchmarking on Stock OS is now still playing music and going strong after 9 hours of music playback |
| 19:12:33 | OlsroFR | the battery indicator indicates me that there is still at least 1/3 of battery left |
| 19:20:38 | | Quit OlsroFR (Quit: Client closed) |
| 19:58:38 | | Quit Everything (Ping timeout: 255 seconds) |
| 20:00 |
| 20:12:04 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 20:12:04 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 20:13:32 | | Join massiveH [0] (~massiveH@2600:4040:a982:5400:d01a:5121:6a30:a1da) |
| 20:31:53 | speachy | jfc.. another big bot storm, Apple and Baidu this time. |
| 20:33:03 | speachy | oh, and OpenAI too. |
| 20:42:00 | rb-bluebot | Build Server message: New build round started. Revision da9d67a0fe, 345 builds, 9 clients. |
| 20:42:01 | rb-bluebot | Button queue handling is split from main button driver by William Wilgus |
| 20:42:35 | _bilgus_ | I was looking at g#570 |
| 20:42:38 | rb-bluebot | Gerrit review #570 at https://gerrit.rockbox.org/r/c/rockbox/+/570 : Remove scroll thread and power scrollers when waiting for buttons. by Michael Sevakis |
| 20:42:56 | *** | Saving seen data "./dancer.seen" |
| 20:43:17 | _bilgus_ | I'm not so keen on the remote scroll thread part as I don't hve any devices with a remote screen |
| 20:43:57 | _bilgus_ | I'm guessing the likelihood of finding a dev with a remote screen is probably slim to none as well |
| 20:44:37 | speachy | prices for the iriver h1xx/h3xx are stupidly high |
| 20:49:04 | _bilgus_ | the iriver is also the only device we have with eprom |
| 20:49:17 | _bilgus_ | (a real one) |
| 20:49:53 | speachy | is it also the only one that still uses a separate USB<->IDE interface instead of our homegrown usb stack? |
| 20:49:58 | _bilgus_ | I think I might just implement this and see if we get fallout |
| 20:50:51 | speachy | btw, I need to do some OS updates on our server soonish, was thinking this weekend would be a good time |
| 20:56:51 | | Quit jn (Ping timeout: 252 seconds) |
| 20:57:23 | | Join jn [0] (~quassel@2a0a-a549-e64c-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de) |
| 20:57:23 | | Quit jn (Changing host) |
| 20:57:23 | | Join jn [0] (~quassel@user/jn/x-3390946) |
| 20:59:43 | rb-bluebot | Build Server message: Build round completed after 1063 seconds. |
| 20:59:45 | rb-bluebot | Build Server message: Revision da9d67a0fe result: All green |
| 21:00 |
| 21:06:33 | rb-bluebot | Build Server message: New build round started. Revision 12aea7dae6, 345 builds, 9 clients. |
| 21:06:33 | rb-bluebot | s5l87xx: Add support for S5L8720 to the GPIO driver by Vencislav Atanasov |
| 21:09:05 | | Join jn_ [0] (~quassel@user/jn/x-3390946) |
| 21:09:24 | | Quit jn (Ping timeout: 276 seconds) |
| 21:16:03 | _bilgus_ | at your leisure.. |
| 21:22:20 | rb-bluebot | Build Server message: Build round completed after 949 seconds. |
| 21:22:22 | rb-bluebot | Build Server message: Revision 12aea7dae6 result: All green |
| 21:46:18 | | Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647) |
| 21:53:36 | | Quit jn_ (Ping timeout: 276 seconds) |
| 21:53:44 | | Join jn [0] (~quassel@2a0a-a549-ed88-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de) |
| 21:53:44 | | Quit jn (Changing host) |
| 21:53:44 | | Join jn [0] (~quassel@user/jn/x-3390946) |
| 22:00 |
| 22:42:58 | *** | Saving seen data "./dancer.seen" |
| 22:58:44 | _bilgus_ | I can't seem to get the second half of g570 to work without crashing or not letting usb work maybe i'm missing something |
| 23:00 |
| 23:26:34 | | Quit COMPL_EXE (Ping timeout: 260 seconds) |
icon identifies that the person is a core developer (has commit access).