--- Log for 01.12.117 Server: orwell.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 months and 1 day ago 00.06.46 # it's not since it's triggering DMA on demand 00.07.05 # I also don't get why it has to worry about alignment if it's just copy in memory 00.07.57 # ....I suppose for the dma on demand 00.08.15 # but that should just be going and refreshing the screen continually 00.08.28 # while it's on anyway 00.09.34 # the LCD looks set up that way but then lcd_update_rect fiddles with it 00.11.02 # <_Bilgus> really the datasheet only covers LCDIF for the chip I didn't even consider the LCD controller may have its own limitations but I wouldn't have expected that to hang the device 00.12.36 # the controller is definitely some Renesas model. the e200v1 has a renesas controller and a continuous DMA auto refresh 00.16.46 # can't say "definitely". it just has that look. more registers than e200's 00.24.42 # <_Bilgus> Note2. Data are written to GRAM in four-words when operating in high speed mode, the dummy write 00.24.42 # <_Bilgus> operations should be inserted depending on the window address area. For details, see the High-Speed RAM 00.24.42 # <_Bilgus> Write Function section. 00.28.21 # If it's that ilitek thing, the datasheet is a dead ringer for a renesas controller, down to the register names, addresses and functions 00.28.56 # I'd change the setup altogether to do auto refresh 00.29.40 # there'd be no register fiddling or DMA waits in the update function then 00.29.56 # <_Bilgus> yeah thats the ilitek one the sitronix data sheet was written with crayon and translated from chinese or something 00.31.40 # <_Bilgus> though the st datasheet states: Notes1: The ST7781 requires no dummy write operation in high-speed write operation. 00.33.42 # <_Bilgus> I wonder if they are similar enough in operation to work like you suggest 00.35.50 # they both appear intended for that. the set up in the driver included front and back porch blanking intervals for vsync 00.36.31 # <_Bilgus> yeah there is also some pretty neat built-ins for video/still/resizing 00.36.53 # <_Bilgus> I doubt they are utilized in the driver though 00.37.02 # this shouldn't need more than lcd-memframe.c and a write-buffered framebuffer 00.37.02 # <_Bilgus> well in OUR driver 00.40.19 # some targets can't really reach their full hw potential because of the simplistic lcd interface 00.41.34 # gigabeat S has a pretty hefty image processing unit that can interesting things and I'm not sure how i'd take advantage of it atm 00.52.07 # <_Bilgus> yep pretty sure its over my head I get the idea but can't even tell what needs to be removed vs added to implement lcd-memframe 00.54.56 Quit duncan^ (Quit: WeeChat 1.9.1) 00.56.15 Quit Moarc (Ping timeout: 248 seconds) 00.58.10 Join Moarc [0] (~chujko@a105.net128.okay.pl) 01.01.14 Join MrZeus_ [0] (~MrZeus@2a02:c7f:7066:fb00:cda2:f27e:7272:1e90) 01.07.28 # <[Saint]> OK. I now have the start of the dynamic overflow menu working. 01.07.46 # <[Saint]> I also discovered a bug in the display logic for preloaded images. 01.07.53 # <[Saint]> But I can work around this. 01.09.56 Part chrisb ("rcirc on GNU Emacs 27.0.50") 01.10.39 Quit dandels_ (Ping timeout: 248 seconds) 01.13.21 *** Saving seen data "./dancer.seen" 01.15.27 # _Bilgus: set up DVI mode, it appears. start the dot clock and forget it. don't mess with controller registers after setup. make sure frame buffer isn't cached. 01.16.04 # <_Bilgus> region `IRAM' overflowed by 1828 bytes 01.16.11 # looks fairly clear from the LCDIF dics 01.16.16 # *docs 01.16.26 Quit michaelni (Ping timeout: 240 seconds) 01.28.41 # <_Bilgus> nm it already has the frame buffer I think I have a decent idea now 01.28.58 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 01.47.26 Quit duo8 (Ping timeout: 248 seconds) 01.49.48 Join dandels_ [0] (~dandels@unaffiliated/dandels) 01.50.25 Quit almog1006 (Quit: Page closed) 02.21.03 Quit dandels_ (Ping timeout: 240 seconds) 02.51.04 Join duncan^ [0] (UNKNOWN@unaffiliated/yulax) 02.55.16 Quit jhMikeS (Ping timeout: 268 seconds) 03.07.32 Quit MrZeus_ (Ping timeout: 264 seconds) 03.13.23 *** Saving seen data "./dancer.seen" 03.13.28 Join Huntereb_ [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) 03.18.52 Join prof_wolfff_ [0] (~prof_wolf@201.red-83-54-194.dynamicip.rima-tde.net) 03.22.40 Quit Huntereb (*.net *.split) 03.22.40 Quit prof_wolfff (*.net *.split) 03.22.42 Quit ranmachan (*.net *.split) 03.26.21 Quit Huntereb_ (Quit: See ya!) 03.26.29 Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) 03.27.13 Join ranmachan [0] (~ranma@yumi.uguu.de) 03.39.54 Join mendelmunkis [0] (~Moshe@ool-3f8fc49c.dyn.optonline.net) 03.41.36 Quit mendelmunkis (Remote host closed the connection) 04.50.27 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 04.54.56 Quit jhMikeS (Ping timeout: 260 seconds) 05.13.24 *** Saving seen data "./dancer.seen" 07.13.25 *** No seen item changed, no save performed. 07.19.07 Join edhelas [0] (~edhelas@149-210-220-39.colo.transip.net) 07.22.25 # hey, here's an update : https://paste.ubuntu.com/26087008/ 07.23.05 # when do I perform the hard-resets? is it at the end or can I intervene now? I'm impatient 07.23.31 # do those hard resets help recover the disc? 07.28.47 Join almog1006 [0] (4d8bf186@gateway/web/freenode/ip.77.139.241.134) 07.49.01 # this thing is fried 07.49.05 # i'm trashing it 07.53.57 Quit skinkitten (Quit: Leaving) 07.54.08 Join ender` [0] (krneki@foo.eternallybored.org) 08.07.39 Join petur [0] (~petur@rockbox/developer/petur) 09.00.22 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.12.30 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.13.26 *** Saving seen data "./dancer.seen" 09.24.32 # <_Bilgus> I have as yet been unable to get dotclk to work properly but that may be my inexperience, I've gotten it to display scattered and mirrored image but mainly just a grey white screen 09.26.04 # _Bilgus: dotclk requires extra wires, I am not sure those are wired. Also the controller needs to be switched to dotclk mode, on some controllers this is controlled by pins on the controller itself 09.26.36 # <_Bilgus> as far as the multiples of 4 It crashed on the oscope app every time the indicator got to the right of the screen even with it bounded properly so maybe something else is up but it seemed to work properly after that 09.27.46 # <_Bilgus> I kinda figured there was some reason you didn't implement dotclk on some device but did on others maybe JHMikeS will have better luck 09.28.58 # _Bilgus: on the Zen, I don't have a choice, dotclk is the only available mode 09.29.23 # and believe me it's the most painful code I had to write because the stmp3700 has hardware bugs in the dma and lcdif 09.30.24 # the imx233 is slightly different since it has a dedicated lcdif dma so it should work better 09.33.35 # I can have a try at it this weekend, although I am not convinced dotclk brings much advantage in our case 09.34.11 # _Bilgus: actually there is this comment in the file by me: 09.34.21 # <_Bilgus> I did notice that when I started adding support for memframe I 1 had to move some sections of memory around and related it added a few KB to the image as well 09.34.25 # WARNING the B1P22 and B1P24 pins are used by the tuner i2c! Do NOT drive them as lcd_dotclk and lcd_hsync or it will break the tuner! 09.34.47 # <_Bilgus> ah so they are shared with it then I take it? 09.35.37 # <_Bilgus> like literally break the tuner? If so I suppose its a good thing I don't use it for the radio 09.35.47 # _Bilgus: no, lcd_vsync and lcd_dotclk don't go to the lcd most probably 09.35.58 # so at best you can hope for vsync mode, not dotclk 09.36.21 # <_Bilgus> sounds like diminishing returns 09.37.47 # I think it's very similar to dotclk, it has continuous update 09.38.51 # <_Bilgus> now as for the patch< is there any reason you mod(height, 2) even though it only needs to be even? 09.39.11 # <_Bilgus> or does that work out to the same ASM as height & 1? 09.40.45 # I'm pretty sure the compiler optimizes this to a bit mask 09.47.11 Join dandels_ [0] (~dandels@unaffiliated/dandels) 09.49.21 # _Bilgus: should I push g#1751 ? it can't make it worse anyway 09.49.23 # 3Gerrit review #1751 at http://gerrit.rockbox.org/r/1751 : 3Fuze PLUS Fix lcd_update_rect() by William Wilgus 09.51.47 # <_Bilgus> If you want but if I'm successful with VSYNC its obsolete, I suppose its a decent stop gap 09.53.36 # _Bilgus: it documents a problem, that might be useful to know 09.57.02 # <_Bilgus> I'd like to get someone with the other lcd and see if it crashes for them as well my device has the ilitek controller maybe OP will check in and we can ask him for his lcd model as well [ ] 09.58.26 # _Bilgus: what is your lcd model? I don't remember which one my fuze+ uses but I can check tonight 09.58.57 Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:d49:3b44:d479:7b05) 09.59.34 # I think mine has st7783 10.00.08 # <_Bilgus> thats the other one mine is ili9325 10.00.10 Quit dandels_ (Ping timeout: 276 seconds) 10.00.44 # <_Bilgus> that pretty much rule out if its the device versus the LCD 10.01.29 # _Bilgus: if it hangs, it sounds like an lcdif problem 10.03.32 # <_Bilgus> I'd like to think it wasn't a problem with the imx233 you'd think there would be an eratta by now I mean it is pretty rarely an issue since everything above 4 is a multiple of two but still 10.04.41 # _Bilgus: is the full device hanging or just the LCD? 10.04.57 # because the LCD cannot hang the SoC, there is no feedback from LCD to SoC 10.05.02 # <_Bilgus> the whole device no usb no power off.. 10.05.28 # <_Bilgus> ah its just a dumb interface huh so maybe it is the processor 10.07.28 # yeah so sounds like an lcdif problem, the driver waits for the lcdif to be ready before sending anything. If for some reason the interface thinks the dma did not send enough data, this will hang 10.11.06 # <_Bilgus> Unfortunately it didn't solve the other bug OP reported not that I figured they were related 10.12.24 # what is the other bug? 10.13.38 # <_Bilgus> peak meter in the voice recorder 10.14.26 # what is the problem? 10.15.52 # <_Bilgus> it doesn't work, My WAG is its probably reading the wrong channel or wrong interface but I haven't looked into it yet besides verifying that it exists in DEV and 3.14 10.16.20 # <_Bilgus> he said it still records fine so its really not a detriment 10.16.37 # jhMikes noticed in his pcm rework that the current imx233 code to get the peak buffer is wrong, I forgot to change it when I did some changes in the rest of the pcm driver 10.16.58 # it does not return the whole uffer 10.17.02 # *buffer 10.19.36 # at least for DAC it is wrong, not sure for ADC and how the peakmeter in voice recorder works 10.24.25 # * pamaury has to go 10.28.36 Quit pamaury (Ping timeout: 246 seconds) 10.39.31 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 10.39.33 # pamaury: (log) So I dived in atj213x boot rom. It has quit a few booting options. It first tries to boot from NAND, SD, SPI flash, ATA, I2C eeprom and finally jumps to USB ADFU handler if all fails 10.41.17 Part almog1006 11.03.05 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.11.11 Quit paulk-gagarine (Ping timeout: 248 seconds) 11.11.50 Join dovber [0] (~dovber@2600:8801:3180:19:beee:7bff:fee3:335f) 11.13.28 *** Saving seen data "./dancer.seen" 11.13.41 Quit dovber_ (Remote host closed the connection) 11.13.51 Join paulk-gagarine [0] (~paulk-gag@gagarine.paulk.fr) 11.30.14 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 11.58.40 Quit pamaury (Ping timeout: 248 seconds) 12.22.34 Quit Riku (Ping timeout: 240 seconds) 13.13.32 *** Saving seen data "./dancer.seen" 13.35.18 Quit petur (Quit: Leaving) 14.00.03 Quit _meg (Ping timeout: 250 seconds) 14.02.16 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 14.04.37 Join _meg [0] (~notsure@211.25.203.45) 14.17.54 Join xorly [0] (~xorly@193.85.203.185) 14.28.57 Join chrisb [0] (~chrisb@172.58.201.254) 15.03.18 Join smoke_fumus [0] (~smoke_fum@188.35.176.90) 15.13.36 *** Saving seen data "./dancer.seen" 15.19.59 Quit wodz (Ping timeout: 258 seconds) 15.33.56 Quit xorly (Ping timeout: 240 seconds) 15.55.05 Join xorly [0] (~xorly@193.85.203.185) 16.05.48 Join johnb2 [0] (~johnb2@p5B3AFFEE.dip0.t-ipconnect.de) 16.25.06 Join Acou_Bass [0] (~Acou_Bass@host-89-241-245-109.as13285.net) 16.26.25 Join amayer [0] (~amayer@24.152.198.8.res-cmts.eph2.ptd.net) 16.35.10 Quit xorly (Ping timeout: 250 seconds) 16.52.27 Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:d49:3b44:d479:7b05) 17.10.07 Quit Acou_Bass (Ping timeout: 248 seconds) 17.13.39 *** Saving seen data "./dancer.seen" 17.15.05 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 17.21.59 Quit MrZeus (Read error: Connection reset by peer) 17.24.37 Join MrZeus [0] (~MrZeus@81.144.218.162) 17.25.53 Join xorly [0] (~xorly@193.85.203.185) 17.33.31 Join Acou_Bass [0] (~Acou_Bass@host-89-241-245-109.as13285.net) 17.40.00 Quit xorly (Ping timeout: 248 seconds) 17.42.33 Quit MrZeus (Quit: Leaving) 17.47.45 Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:d49:3b44:d479:7b05) 17.58.28 Quit johnb2 (Ping timeout: 255 seconds) 18.02.06 Quit Acou_Bass (Remote host closed the connection) 18.10.20 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 18.22.47 Join johnb2 [0] (~johnb2@p5B3AFFEE.dip0.t-ipconnect.de) 18.25.12 Quit sielicki (Ping timeout: 268 seconds) 18.30.24 # _Bilgus (logs): For the record, my (son's) read-only clip+ has now fully gone bad. It is usually just showing the 32MB partition. I tried getting it into Bootload USB mode (UP key pressed while connecting to USB). If briefly showed the Rockbox logo, then the "Debug->View I/O Ports" screen, then an ATA error. 18.32.19 # <_Bilgus> just a matter of time I suppose I'm sure the extra fiddling didn't do it any favors 18.32.45 # Might be true. 18.33.17 # <_Bilgus> interesting that it has 32 mb partition and recovers from it though 18.33.48 # That is not reliably repeatable. 18.33.58 # <_Bilgus> makes me wonder if its a physical issue on the board or the chip 18.34.58 # I was thinking about that too. My son surely gave it a hard time. The display also dimmed or was dark every now and then. 18.35.14 # I will open it and check if I can spot anything. 18.35.19 # <_Bilgus> get someone to slap some flux on there and a good drag soldering with some real lead solder 18.36.09 # <_Bilgus> the wholde lead free solder thing is a detriment to electronics not to mention the terrible atmosphere these players endure 18.37.07 # Different topic: I tried adding the MB patch on top of the Power Savings. I doesn't merge automatically. 18.37.24 # <_Bilgus> but it could just be that the chip is kaput and the cells sometimes reset enough to pass muster to the controller 18.38.15 # <_Bilgus> no I would suspect it wouldn't lots of changes and MB hasn't been rebased in a while 18.39.33 # <_Bilgus> speaking of have you tried out the latest PS patch on gerrit? I changed a few thing but it should be good to go even did a preliminary manual entry 18.40.23 # yes, I compiled today for fuze, clipp and zip. 18.40.33 # Fuze seems just fine. 18.41.20 # The other I need to test further. 18.41.42 # FuzeV2 I still have to compile. 18.43.51 # <_Bilgus> the zip is still a bit sluggish on the display when cpu boost is off like with the cube demo but Its much better than it was and perfectly suitable for playing music and browsing menus 18.44.31 # Another hardware question: In the lot of fuzes I bought on *bay there are 2 Fuze v1 devices, that do not connect to usb at all. Charging however works, also the SD card. Is this more likely a mechanical problem or electronic? 18.45.08 # It is similar for the clip+ at first glance. 18.45.53 # Like you see the screen refresh from top to bottom. 18.46.35 # Have you done any tests what are the respective power savings of each feature? 18.46.58 # bbl 18.48.27 # <_Bilgus> that sounds mechanical but It could be that someone fried them too 18.49.04 # <_Bilgus> MB should be good now I rebased it and its parent commit 18.51.15 # <_Bilgus> not beyond some initial stuff 100- 50% battery and between voltage (low) and the second run with all optimization it increased by ~40% 18.52.29 # <_Bilgus> but did one optimization save 37% and the other two save 3% idk something that I need to test over a few days 19.07.54 Join lebellium [0] (~hexchat@89-93-177-206.hfc.dyn.abo.bbox.fr) 19.13.40 *** Saving seen data "./dancer.seen" 19.28.18 # _Bilgus 19.28.35 # <_Bilgus> ? 19.28.40 # : the patch still doesn't merge on master 19.29.27 # <_Bilgus> MB onto master or PS onto MB? 19.29.57 # MB 19.30.19 # I tried MB on PS first and get compile errors. 19.30.42 # then MB on master, git errors 19.31.07 # <_Bilgus> ok try this first go back to master do git pull --rebase 19.32.06 # <_Bilgus> actually better would just be to review the whole thing 19.33.02 # <_Bilgus> do git review -d I697b3d0499f85e789c3020bc2133fbe0023f72a2 && git branch -m multiboot_12_1 19.34.28 # Hm, I have added the review feature a while ago, but failed to specify the repository. 19.34.29 # No '.gitreview' file found in this repository. 19.34.29 # We don't know where your gerrit is. Please manually create 19.34.29 DBUG Enqueued KICK johnb2 19.34.29 # a remote named gerrit and try again. 19.34.46 # Any hint how to set this? 19.35.42 # <_Bilgus> give me a second i'll have to look it up its been a long while 19.38.37 # <_Bilgus> you already have a git account and ssh key correct? 19.38.43 # yes 19.39.21 # <_Bilgus> git remote set-url --push origin ssh://yourusername@gerrit.rockbox.org:29418/rockbox 19.41.16 # I still get the "No '.gitreview' file found in this repository." after that. 19.41.18 # <_Bilgus> and I think fetch is the same git remote set-url --fetch origin ssh://yourusername@gerrit.rockbox.org:29418/rockbox 19.42.36 # <_Bilgus> nope fetch would be git remote set-url --fetch origin git://git.rockbox.org/rockbox 19.43.06 # <_Bilgus> then type git remote -v and it should list the entries for push and fetch 19.43.18 # <_Bilgus> push should be the ssh your username 19.43.27 # <_Bilgus> and fetch should list git 19.45.31 # I does, but still review doesn't work: https://pastebin.com/xfgVs0LP 19.47.51 # I don't want to bother you too much, but it is strange that fetching MB onto master doesn't work. I can try and clone the whole repo again. 19.50.04 Quit dys (Ping timeout: 255 seconds) 19.50.23 # <_Bilgus> it doesn't have the gerrit ones in there try git remote add gerrit ssh://johnb2@gerrit.rockbox.org:29418/rockbox 19.51.00 # <_Bilgus> then when you type git remote -v it should have two gerrit entries and the two origin entries 19.51.04 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 19.51.19 # yes, it now does 19.51.31 # <_Bilgus> now it should work 19.52.16 # yep, it did something. So now this is the MB and I have to add the pOwSav? 19.53.41 # Can I still do this with cherry pick? 19.54.04 # <_Bilgus> git review -d I04137682243be92f0f8d8bf1cfa54fbb1965559b && git branch -m powersave 19.54.47 # <_Bilgus> next type git checkout multiboot_12_1 19.55.13 # <_Bilgus> and finally git rebase powersave 19.55.29 # <_Bilgus> and it should allpy everything for you 19.57.08 # git checkout multiboot_12_1 or multiboot_12? the first gives me: error: pathspec 'multiboot_12_1' did not match any file(s) known to git. 19.58.14 # <_Bilgus> the first review you did 19.58.44 # <_Bilgus> if you can't find it it might have not renamed type 'git branch' 19.59.38 # <_Bilgus> it'll bring up a list if it didn't rename it'll be something like review/gerrit/bleh/williamwilgus/I697b3d0499f85e789c3020bc2133fbe0023f72a2 20.00.41 # <_Bilgus> if so checkout that branch and do git branch -m multiboot_12_1 20.01.04 # <_Bilgus> and finally finish with git rebase powersave 20.01.31 # <_Bilgus> you could use that big long ID too without rename any branch but that gets tedious 20.01.31 # it is compiling now (with multiboot_12). 20.02.05 # Thanks for walking me there ;-) 20.03.00 # <_Bilgus> so to review you, reviewed + renamed multiboot, you reviewed + renamed powersave, switched to multiboot and rebased it with powersave 20.03.38 # <_Bilgus> thats the same way I learned how to use it too from [Saint] 20.04.03 # _Bilgus: I can confirm the oscilloscope bug on fuze+ with st display 20.04.07 # <_Bilgus> so you are welcome 20.04.09 # I will save that conversation and try and understand it later ;-) 20.04.50 # <_Bilgus> pamaury then I'd say its for sure a bug in LCDIF thanks for checking 20.05.56 # _Bilgus: I'll have a try at vsync mode tonight/this weekend 20.06.51 # <_Bilgus> cool I'm sure your code will be a lot more likely to work :p otherwise I plan to mess with it monday or tues 20.07.14 Join Acou_Bass [0] (~Acou_Bass@host-89-241-245-109.as13285.net) 20.07.23 # it requires some care, one need to change not only the driver's code but also some LCD registers 20.08.39 # <_Bilgus> yeah i was reading the data sheets the timing seems like a PITA 20.10.34 # <_Bilgus> might be a good idea to do most of the leg work in a macro and have it use the actual pixclk so it is at least easily changed 20.14.42 # _Bilgus : build is running now on the clip+. Thanks. 20.15.59 # <_Bilgus> nice I haven't tried on my main clip+ yet since I only run sd builds there but I do love the way multiboot allows switching between builds 20.16.33 # <_Bilgus> I think a plugin that searches and allows selection for next boot might be a nice addition 20.19.16 # Specifying the path still seems to be picky. I only use Notepad++. I had "/rb/clipp" and it complained about No .rockbox directory. I changed it to "/rb/clip" with Notepad++ and it worked. No additional chars or linebreaks in both cases. 20.20.59 # additional = trailing 20.24.40 # <_Bilgus> If you use a trailing / I think it should work properly 20.25.18 Join dandels_ [0] (~dandels@unaffiliated/dandels) 20.26.42 # <_Bilgus> its picky though because I was going for the absolute smallest code size possible since a few of the targets were down to not fitting by 10 bytes and such, JhMikeS and I have fixed that now though so I might revisit it later to make it slightly more robust 20.27.15 # I will try the trailing /. 20.29.48 Join xorly [0] (~xorly@ip-86-49-24-93.net.upcbroadband.cz) 20.30.38 Quit Acou_Bass (Remote host closed the connection) 20.31.37 Quit C-Keen (Quit: WeeChat 1.9.1) 20.33.47 Join Acou_Bass [0] (~Acou_Bass@host-89-241-245-109.as13285.net) 20.34.08 Join dys [0] (~dys@tmo-098-252.customers.d1-online.com) 20.35.07 Quit Acou_Bass (Client Quit) 20.39.51 Join Acou_Bass [0] (~Acou_Bass@host-89-241-245-109.as13285.net) 20.39.55 Quit Acou_Bass (Remote host closed the connection) 20.42.13 Join Acou_Bass [0] (~Acou_Bass@host-89-241-245-109.as13285.net) 20.52.14 Join sielicki [0] (~sielicki@unaffiliated/n1cky) 20.52.45 Quit johnb2 (Ping timeout: 260 seconds) 20.53.58 Join lukeoftheaura [0] (~lukeofthe@94.185.86.50) 20.54.39 # is it possible to set the database to only scan a specific fonder, and then have a separate folder for non-music audio files that isn't scanned? 20.56.53 # lukeoftheaura: see https://download.rockbox.org/manual/rockbox-ipodvideo/rockbox-buildch4.html 20.57.09 # you can create file database.ignore in directories you want the database to ignore 20.59.32 # ok 21.00.13 # thanks 21.04.12 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:584:1b0e:3be5:84bf) 21.09.21 Quit Jon (Ping timeout: 264 seconds) 21.10.27 Join Jon [0] (jon@dow.land) 21.10.28 Quit lukeoftheaura (Quit: Leaving) 21.11.38 Join Jinx [0] (Dojo@unaffiliated/jinx) 21.11.56 Quit sielicki (Ping timeout: 240 seconds) 21.13.38 Join sielicki [0] (~sielicki@unaffiliated/n1cky) 21.13.41 *** Saving seen data "./dancer.seen" 22.01.44 Join _jhMikeS_ [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 22.01.44 Quit jhMikeS (Disconnected by services) 22.01.45 Nick _jhMikeS_ is now known as jhMikeS (~jethead71@d192-24-173-177.try.wideopenwest.com) 22.05.42 Quit sielicki (Read error: Connection reset by peer) 22.05.52 Quit amayer (Quit: Leaving) 22.09.17 Join sielicki [0] (~sielicki@unaffiliated/n1cky) 22.13.34 Quit dandels_ (Ping timeout: 248 seconds) 22.20.50 Quit dys (Ping timeout: 246 seconds) 22.33.19 # <__builtin> _Bilgus: I don't quite understand your code in g#1751 22.33.20 # 3Gerrit review #1751 at http://gerrit.rockbox.org/r/1751 : 3Fuze PLUS Fix lcd_update_rect() by William Wilgus 22.33.36 # <__builtin> why would you use the comma operator here? "w += x, x = 0" 22.34.12 # <_Bilgus> that was actually already in from the code mike gave me for it but it is valid c 22.35.14 # <__builtin> I know it's valid, but why not make it less convoluted? 22.36.20 Join bp0 [0] (~bp@216.16.66.181) 22.36.20 Quit bp0 (Changing host) 22.36.20 Join bp0 [0] (~bp@unaffiliated/bp0) 22.36.24 # <_Bilgus> sure 22.45.11 # geez, the fuck in convoluted about a comma operator? 22.46.14 # <__builtin> maybe confusing would be a better word 22.46.18 # <_Bilgus> it is easy to overlook scanning the code 22.47.29 # __builtin: to whom, those who don't know C? 22.48.08 # <__builtin> and those trying to learn, yes 22.48.23 # <__builtin> I just think a block with two statements would be more clear in this case 22.48.34 # __builtin: then they should see those things if they want to learn 22.49.10 # __builtin: meh, people object to weird things for some reason, often because someone said they should 22.50.11 # <__builtin> I mean, either one works, but one is just more common 22.50.28 # though I'll admit I put it there about 10 years ago just so someone would complain about it. 22.50.36 # <__builtin> if you insist on keeping it, go ahead 22.51.11 # I don't 22.52.45 # I'm just amused a bit 23.01.44 Quit ender` (Quit: It's not a dictatorship. It's an alternate democracy.) 23.02.31 # if C wasn't the terrible language it is, I wouldn't mind the comma operator, but C is a terrible language, the comma operator does not help with that. At least modern compilers warn about misleading indentation, but we don't use modern compilers either ;) 23.04.34 # It's just slightly less terrible than others 23.13.42 *** Saving seen data "./dancer.seen" 23.38.22 Quit chrisb (Excess Flood) 23.46.46 Quit _meg (Ping timeout: 255 seconds) 23.47.40 Join _meg [0] (~notsure@211.25.203.45) 23.48.06 # <_Bilgus> Ok __builtin I spread it out a bit and even knocked off a few instructions in the assembly while I was at it 23.50.26 Quit ZincAlloy (Quit: Leaving.) 23.52.09 # <_Bilgus> oh and pamaury h &1 was quite a bit shorter than h%2 i'm guessing since its not unsigned but I would have figured the compiler would have figured it out