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 2018-02-19

00:05:41 Join MrZeus [0] (~MrZeus@2a02:c7f:7066:fb00:d533:33c1:8bca:b04b)
00:05:59 Join quaz0r [0] (
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] (
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] (
01:22:13 Quit michaelni (Ping timeout: 265 seconds)
01:34:32 Join michaelni [0] (
01:35:10***Saving seen data "./dancer.seen"
01:57:03 Quit dys (Ping timeout: 248 seconds)
02:01:52dongsrockbox runs OS-less on imx223 right?
02:01:59dongsnot some userapp on top of lunix?
02:15:14pamaurydongs: yes
02:15:36pamaurywe ship our own kernel on the imx233
02:28:56dongshow about OF? is that lunix?
02:32:53pamaurythat 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:33:00dongsthank you
02:33:04pamauryoh I remember now, ThreadX
02:33:15dongshmm that sounds very familiar
02:34:13pamaurybut really ThreadX just does the threading part, most of the OS is propietary
02:39:05dongsthinking 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:28dongsone of the faster STM32s with USB host should almost do it but would need careful coding
02:40:30pamaurysaratoga is the audio expert, but he is not only now
02:41:03dongsyea 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.
02:46:06saratogadongs: i think it comes down to what decoder you want to use
02:46:22saratogamad and ffmpeg assume you have a full 32 bit system
02:47:13saratogaand multipliers
02:48:24saratogaif you have that, 100 mhz and ~200 KB plus whatever your USB stack uses is easy
02:49:07saratogaif you can't at least do 32 bit multiplies (and ideally 32x32=64 bit multiplies), things are much harder
02:50:22dongscortex m3/m4 has imul or wahtever, no?
02:51:05saratogathat is thumb2?
02:54:30saratogai think that supports the usual arm long multiply instructions, but i haven't used one
02:55:36saratogayeah looks ok
02:57:48 Quit terminalator (Quit: terminalator)
02:58:09saratogaapparently m3 and above have normal armv5 equivalent multipliers
02:58:16saratogam0 does not fwiw
02:58:23dongs the "mhz" column here is what it takes to decode ~roughly?
02:58:24 Join terminalator [0] (terminalat@gateway/vpn/privateinternetaccess/terminalator)
02:58:47dongsyeah, m0 is crap, there's nothing fast in m0 series anyway
02:59:13saratogamp2 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] (
03:27:32 Quit jhMikeS (Ping timeout: 260 seconds)
03:30:31 Join jhMikeS [0] (
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] (
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:46pamauryBilgus: should I push g#1751
07:36:48fs-bluebot3Gerrit review #1751 at : 3Fuze PLUS Fix lcd_update_rect() by William Wilgus
07:50:24 Join LinusN [0] (
07:55:52dongsi would
07:57:52dongsactually what, why is it replacing macros with what is basically same thing
08:01:19 Quit advcomp2019 (Ping timeout: 248 seconds)
08:02:03pamaurydongs: 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:21dongs& 1 and % 2 are functionally identical, no?
08:07:17dongsi dont really understand the limitation text tho.
08:07:27dongswhich is why im confused on % 4 change.
08:07:41dongsits not functionally identical to the previous version.
08:10:00dongs1st version checks if w is even, second version checks if w is not multiple of 4
08:14:51pamaurydongs: the % vs & is just because he insisted that & must be faster, which is kind of stupid as I pointed out
08:15:19dongscorrect, it likely is faster
08:15:25dongstho compiler would probably generate same code
08:15:30pamauryprobably not because the compiler will optimize this
08:15:31pamaurythe 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:45dongsis this some ILI thing?
08:16:10pamauryit sounds more like a problem with the imx233 lcd controller
08:16:16dongsyeah iw a gonna sayt
08:16:54dongscuz 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:04dongsand i never heard of them needing alignment
08:17:44pamaurythey might need dummy writes, this is common
08:17:52dongsso why the change for % 2 == 1 vs % 4?
08:18:04pamaurybut the problem we have is the imx233 lcd block locking up
08:18:18pamauryie it's not related to the lcd, but to the block that sends data to the lcd
08:18:37pamaury(in the soc)
08:18:50dongsI understood it back when you said < pamaury> it sounds more like a problem with the imx233 lcd controller
08:20:30pamauryif 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:11pamauryI don't know if what I am saying is clear
08:21:35dongsbut how did the OLD code work then?
08:21:48dongsthe change is only in condition right
08:22:24dongsold code would pad 3 pixels whenever w was even.
08:22:26pamauryit 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] (
08:22:36dongsfixed version pads 3 pixels whenever w is multiple of 4
08:23:05dongsohh, 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@
08:30:20 Quit deevious (Quit: deevious)
08:32:57pamaurydongs: maybe let me summarize (assuming I recall correctly):
08:32:58pamauryon the fuze+, if both h and w are odd, the LCD seems to require at least one dummy write.
08:32:58pamauryalso it seems that if w is not a multiple of 4, the imx233 locks up
08:32:58DBUGEnqueued KICK pamaury
08:32:58pamaurySo 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:58pamaurybut 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:43dongsis common usecase just updating large parts of a screen, or small rectangles?
08:42:02dongslike large = refresh entire 320x240 vs say write a bunch of small 2x2pixel blocks over and over
08:42:36pamauryI think we mostly update big chunks but I might be wrong
08:43:02pamauryI 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] (
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] (
12:13:03 Join jhMikeS [0] (
12:14:58 Quit Jinx (Ping timeout: 255 seconds)
12:27:04 Join Jinx_Dojo [0] (
12:39:55 Join ernestask [0] (
12:48:26Bilgusyeah 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:12Bilgusthe exact amount is back in the logs
12:53:28Bilgusdongs 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:41dongsBilgus: thats what I thought, that entire screen is pushed only
13:12:58 Join amofiuhr_ [0] (
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] (
14:18:49 Join massiveH [0] (
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] (
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] (
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] (
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"

Previous day | Next day