--- Log for 19.02.118 Server: card.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 18 days ago 00.05.41 Join MrZeus [0] (~MrZeus@2a02:c7f:7066:fb00:d533:33c1:8bca:b04b) 00.05.59 Join quaz0r [0] (~quaz@c-24-18-93-195.hsd1.wa.comcast.net) 00.22.01 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 00.25.07 Quit ender` (Quit: If it wasn't for C, we'd be writing programs in BASI, PASAL, and OBOL. — A Programmer (@1Pr0grammer)) 00.30.15 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 00.35.07 Quit jhMikeS (Ping timeout: 264 seconds) 00.53.34 Quit terminalator (Quit: terminalator) 00.53.55 Join terminalator [0] (terminalat@gateway/vpn/privateinternetaccess/terminalator) 00.54.06 Quit ZincAlloy (Quit: Leaving.) 00.58.16 Quit MrZeus (Ping timeout: 240 seconds) 01.00.32 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 01.22.13 Quit michaelni (Ping timeout: 265 seconds) 01.34.32 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 01.35.10 *** Saving seen data "./dancer.seen" 01.57.03 Quit dys (Ping timeout: 248 seconds) 02.01.52 # rockbox runs OS-less on imx223 right? 02.01.59 # not some userapp on top of lunix? 02.15.14 # dongs: yes 02.15.36 # we ship our own kernel on the imx233 02.28.56 # how about OF? is that lunix? 02.32.53 # that depends on the player, but most use it's a proprietary OS, based on Nucleus RTOS or MicroC/OS-II, I don't remember 02.32.59 # ok 02.33.00 # thank you 02.33.04 # oh I remember now, ThreadX 02.33.15 # hmm that sounds very familiar 02.34.13 # but really ThreadX just does the threading part, most of the OS is propietary 02.39.05 # thinking of making some hardware that needs to play back ~128kbit mpeg1-layerII stuff from a custom USB device (source), but wonder if it will be too much work to do on a MCU and I should go fullretard with something like imx 02.39.28 # one of the faster STM32s with USB host should almost do it but would need careful coding 02.40.30 # saratoga is the audio expert, but he is not only now 02.41.03 # yea its not so much the audio part. thats the least of my worries as mp2 is pretty old and should be fairly light 02.45.43 Join saratoga [0] (47e99464@gateway/web/freenode/ip.71.233.148.100) 02.46.06 # dongs: i think it comes down to what decoder you want to use 02.46.22 # mad and ffmpeg assume you have a full 32 bit system 02.47.13 # and multipliers 02.48.24 # if you have that, 100 mhz and ~200 KB plus whatever your USB stack uses is easy 02.49.07 # if you can't at least do 32 bit multiplies (and ideally 32x32=64 bit multiplies), things are much harder 02.50.22 # cortex m3/m4 has imul or wahtever, no? 02.51.05 # that is thumb2? 02.51.48 # ya 02.54.30 # i think that supports the usual arm long multiply instructions, but i haven't used one 02.55.34 # http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/BABFADHJ.html 02.55.36 # yeah looks ok 02.57.48 Quit terminalator (Quit: terminalator) 02.58.09 # apparently m3 and above have normal armv5 equivalent multipliers 02.58.16 # m0 does not fwiw 02.58.23 # https://www.rockbox.org/wiki/CodecPerformanceComparison the "mhz" column here is what it takes to decode ~roughly? 02.58.24 Join terminalator [0] (terminalat@gateway/vpn/privateinternetaccess/terminalator) 02.58.47 # yeah, m0 is crap, there's nothing fast in m0 series anyway 02.58.50 # yeah 02.59.13 # mp2 is pretty multiplier heavy and memory light, so it scales more or less with how many multiplies something can do per second 03.04.15 Quit Moarc (Ping timeout: 248 seconds) 03.05.16 Join Moarc [0] (~chujko@a105.net128.okay.pl) 03.27.32 Quit jhMikeS (Ping timeout: 260 seconds) 03.30.31 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 03.35.05 Quit jhMikeS (Ping timeout: 256 seconds) 03.35.14 *** Saving seen data "./dancer.seen" 04.19.36 Quit terminalator (Quit: terminalator) 04.20.06 Join cohokiller673 [0] (~adambomb@c-24-22-103-176.hsd1.wa.comcast.net) 05.33.37 Quit saratoga (Quit: Page closed) 05.35.15 *** Saving seen data "./dancer.seen" 06.08.22 Quit TheSeven (Ping timeout: 265 seconds) 06.33.19 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 07.35.17 *** Saving seen data "./dancer.seen" 07.36.46 # Bilgus: should I push g#1751 07.36.48 # 3Gerrit review #1751 at http://gerrit.rockbox.org/r/1751 : 3Fuze PLUS Fix lcd_update_rect() by William Wilgus 07.50.24 Join LinusN [0] (~linus@giant.haxx.se) 07.55.52 # i would 07.57.52 # actually what, why is it replacing macros with what is basically same thing 08.01.19 Quit advcomp2019 (Ping timeout: 248 seconds) 08.02.03 # dongs: it also handles negative x or y, but this is not what matters, it's the fix on the parity of w and h which is important 08.03.21 # & 1 and % 2 are functionally identical, no? 08.07.17 # i dont really understand the limitation text tho. 08.07.27 # which is why im confused on % 4 change. 08.07.41 # its not functionally identical to the previous version. 08.10.00 # 1st version checks if w is even, second version checks if w is not multiple of 4 08.14.51 # dongs: the % vs & is just because he insisted that & must be faster, which is kind of stupid as I pointed out 08.15.19 # correct, it likely is faster 08.15.25 # tho compiler would probably generate same code 08.15.30 # probably not because the compiler will optimize this 08.15.31 # the true problem is that the datasheet says h should be a multiple of 2, but in practice if it is not a multiple of 4, it locks out sometimes 08.15.45 # is this some ILI thing? 08.15.47 # (lcdv) 08.16.10 # it sounds more like a problem with the imx233 lcd controller 08.16.16 # yeah iw a gonna sayt 08.16.54 # cuz a a common usecase for those cheap LCDs is writing as little as a few pixels into them after setting xypos and write width 08.17.04 # and i never heard of them needing alignment 08.17.44 # they might need dummy writes, this is common 08.17.52 # so why the change for % 2 == 1 vs % 4? 08.18.04 # but the problem we have is the imx233 lcd block locking up 08.18.18 # ie it's not related to the lcd, but to the block that sends data to the lcd 08.18.37 # (in the soc) 08.18.50 # I understood it back when you said < pamaury> it sounds more like a problem with the imx233 lcd controller 08.20.30 # if w is not a multiple of 4, we add dummy writes to the transfer so that w is a multiple of 4 (actually w=4, if you look at the then branch) and make the imx233 happy 08.21.11 # I don't know if what I am saying is clear 08.21.35 # but how did the OLD code work then? 08.21.48 # the change is only in condition right 08.22.24 # old code would pad 3 pixels whenever w was even. 08.22.26 # it did the same but only checked for w being a multiple of 2 (which is what the datasheet says). Apparently the only piece of code that would trigger the bug is the oscilloscope 08.22.28 Join ender` [0] (krneki@foo.eternallybored.org) 08.22.36 # fixed version pads 3 pixels whenever w is multiple of 4 08.23.05 # ohh, i see, its not a common code path probably because the writes/stuff is bigger than a few pixels right 08.23.49 Join deevious [0] (~Thunderbi@193.226.142.214) 08.30.20 Quit deevious (Quit: deevious) 08.32.57 # dongs: maybe let me summarize (assuming I recall correctly): 08.32.58 # on the fuze+, if both h and w are odd, the LCD seems to require at least one dummy write. 08.32.58 # also it seems that if w is not a multiple of 4, the imx233 locks up 08.32.58 DBUG Enqueued KICK pamaury 08.32.58 # So the obvious solution is, when any of those circumstances happen, to send a number of pixels which is a multiple of 4. For technical reasons on the imx233, the best way to achieve this is to send the whole buffer pretending that w=4 and h=whatever 08.32.58 # but if w*h is a not a multiple of 4, then w=4 and h=bla will send too many pixels, thus we fill those extra pixels: they will be treated as dummy writes by the LCD. The fact that we pads 3 pixels is because we chose w=4. If I had chosen w=16 then I would need to pad 15 08.41.43 # is common usecase just updating large parts of a screen, or small rectangles? 08.42.02 # like large = refresh entire 320x240 vs say write a bunch of small 2x2pixel blocks over and over 08.42.36 # I think we mostly update big chunks but I might be wrong 08.43.02 # I think refreshing really small chunks is rare though, if you think about typical UI elements: we have images, icons and text 09.08.28 Join petur [0] (~petur@rockbox/developer/petur) 09.15.59 Join dys [0] (~dys@2003:5b:203b:100:6af7:28ff:fe06:801) 09.30.41 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.35.21 *** Saving seen data "./dancer.seen" 11.25.28 Quit pamaury (Ping timeout: 276 seconds) 11.35.24 *** Saving seen data "./dancer.seen" 11.39.29 Quit quaz0r (Quit: WeeChat 2.1-dev) 11.55.12 Join quaz0r [0] (~quaz@c-24-18-93-195.hsd1.wa.comcast.net) 12.13.03 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 12.14.58 Quit Jinx (Ping timeout: 255 seconds) 12.27.04 Join Jinx_Dojo [0] (Dojo@adsl-108-202-193-234.dsl.klmzmi.sbcglobal.net) 12.39.55 Join ernestask [0] (~ernestask@78-56-62-157.static.zebra.lt) 12.48.26 # yeah you got it Pamaury also (h & 1) vs h % 2 do generate the same code with O-3? I think but we not with a regular compile so we kinda hint the compiler a bit and it drops two or 3 instructions 12.49.12 # the exact amount is back in the logs 12.53.28 # dongs I think the amount updating doesn't really matter since we usually write to the frame buffer first and then do a full screen update through most of the code 12.55.41 # Bilgus: thats what I thought, that entire screen is pushed only 13.12.58 Join amofiuhr_ [0] (~amofiuhr_@ip240-155-64-186.ct.co.cr) 13.12.58 Quit this_is_a_nick (Read error: Connection reset by peer) 13.35.26 *** Saving seen data "./dancer.seen" 14.18.14 Join amayer [0] (~amayer@107-1-97-172-ip-static.hfc.comcastbusiness.net) 14.18.49 Join massiveH [0] (~massiveH@ool-18e4e27c.dyn.optonline.net) 14.22.55 Quit massiveH (Client Quit) 15.16.32 Quit wodz (Ping timeout: 264 seconds) 15.35.29 *** Saving seen data "./dancer.seen" 17.35.31 *** No seen item changed, no save performed. 17.36.10 Quit petur (Read error: Connection reset by peer) 18.11.07 Join terminalator [0] (terminalat@gateway/vpn/privateinternetaccess/terminalator) 18.36.42 Join krabador [0] (~krabador@unaffiliated/krabador) 18.37.44 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:5910:87dd:48a2:bda2) 18.50.22 Join MrZeus [0] (~MrZeus@2a02:c7f:7066:fb00:3942:5656:cf67:af38) 18.55.16 Quit dys (Ping timeout: 240 seconds) 19.09.38 Quit terminalator (Ping timeout: 260 seconds) 19.15.21 Quit amofiuhr_ (Ping timeout: 276 seconds) 19.24.55 Quit JdGordon (Ping timeout: 263 seconds) 19.35.33 *** Saving seen data "./dancer.seen" 19.43.33 Join lebellium [0] (~hexchat@89-93-177-206.hfc.dyn.abo.bbox.fr) 19.58.51 Join terminalator [0] (terminalat@gateway/vpn/privateinternetaccess/terminalator) 21.08.44 Quit MrZeus (Ping timeout: 256 seconds) 21.13.12 Quit ernestask (Quit: ernestask) 21.35.37 *** Saving seen data "./dancer.seen" 21.50.41 Join MrZeus [0] (~MrZeus@2a02:c7f:7066:fb00:21fd:569e:be6a:8c98) 22.26.52 Join advcomp2019 [0] (~advcomp20@65-131-184-40.sxct.qwest.net) 22.26.52 Quit advcomp2019 (Changing host) 22.26.52 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 22.34.48 Quit amayer (Quit: Leaving) 22.56.48 Quit terminalator (Quit: terminalator) 22.57.31 Join advcomp2019_ [0] (~advcomp20@65-131-184-40.sxct.qwest.net) 22.57.31 Quit advcomp2019_ (Changing host) 22.57.31 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 22.58.39 Quit MrZeus (Ping timeout: 240 seconds) 23.00.38 Quit advcomp2019 (Ping timeout: 260 seconds) 23.22.49 Quit ZincAlloy (Quit: Leaving.) 23.23.29 Quit lebellium (Quit: Leaving) 23.35.38 *** Saving seen data "./dancer.seen"