| 00:22.20 | *** join/#card10badge kri404 (~kri404@90.199.234.48) |
| 00:57.43 | *** join/#card10badge Stormwind_mobile (~Stormwind@dslb-002-206-218-106.002.206.pools.vodafone-ip.de) |
| 01:29.59 | *** join/#card10badge Benjojo (~sid4563@srv-69.nsa.me.uk) |
| 02:27.42 | *** join/#card10badge n0p (~n0p@5.1.86.168) |
| 02:39.05 | *** join/#card10badge user_51_ (~quassel@92.117.245.196) |
| 02:41.13 | *** join/#card10badge n0p_ (~n0p@5.1.86.168) |
| 02:42.14 | *** join/#card10badge verin0x9 (~thelounge@x4e37daa5.dyn.telefonica.de) |
| 02:56.16 | *** join/#card10badge Stormwind_mobile (~Stormwind@dslb-002-206-218-106.002.206.pools.vodafone-ip.de) |
| 03:12.11 | *** join/#card10badge PyroPeter (~pyropeter@april-fools/2013/tenth/pyropeter) |
| 03:29.15 | *** join/#card10badge centzilius (~cent@naofumi.centzilius.de) |
| 07:50.50 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 08:38.24 | Rahix | pippin: Looks great, I'm excited! |
| 08:43.12 | Rahix | I cannot reproduce the USB storage issue ... |
| 08:43.33 | Rahix | Tried stressing it in all sorts of ways but it did not give in |
| 09:07.16 | pippin | what is the reason for.. lib/gfx/LCD/LCD_Driver.c 's static struct framebuffer frambuffer = ... having orientation = FB_O_180, instead of orientation = FB_O_0 ? |
| 09:08.25 | Rahix | I guess because the display is actually upside down? |
| 09:08.48 | pippin | well |
| 09:08.54 | pippin | this is where the orientation of the display is configured |
| 09:09.18 | pippin | and because of this, in the gta like game and lots of other code one has to flip the x and y coordinates around in code to get upside up |
| 09:10.22 | pippin | these displays have 8 software initialization orientations, just like EXIF all the 90 degree turns and their mirrors |
| 09:11.08 | Rahix | I think the _hardware_ display is upside down and the gfx lib adds this FB_O_180 to flip it for normal drawing operations. Your l0dables bypass the gfx lib and write out to the display directly. Thus you need to flip manually |
| 09:13.14 | pippin | ah, yes, this is the gfx lib flipping not the driver flipping |
| 09:14.26 | pippin | the exif-like orientation is set in LCD_Init(); a little trickier - but then possibly entirely fixable at the expense of making the .elf l0dables pushing pixels directly to display "break" |
| 09:30.04 | Rahix | Hmm, I see |
| 09:30.19 | Rahix | How expensive would changing that at runtime be? |
| 09:31.25 | Rahix | Ie, add an API call that says 'I can deal with a properly oriented display' and epicardium will then reinit the display with correct orientation |
| 09:32.30 | pippin | not very, it should be 2-3 bytes out over SPI |
| 09:33.29 | pippin | something similar to https://github.com/Bodmer/TFT_eSPI/blob/master/TFT_Drivers/ST7735_Rotation.h |
| 09:35.32 | pippin | I have a second attempt at glyph caching in my graphic rendering working, but for now I only do caching when the only transformations are translate or scale, not rotate :] |
| 09:36.15 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 09:48.45 | pippin | hm, my card10 ignores the card10.bin i put on the fs now |
| 09:51.46 | Rahix | New firmware release! Download at https://card10.badge.events.ccc.de/en/firmwareupdate/ |
| 09:52.17 | Rahix | Version v1.12 "Leek" finally brings you USB Storage mode, no more rebooting to bootloader to access the filesystem |
| 09:52.41 | Rahix | Full changelog: https://git.card10.badge.events.ccc.de/card10/firmware/blob/master/CHANGELOG.md#v112-2019-10-19-leek |
| 09:55.45 | mue_ | ty |
| 09:57.00 | pippin | Rahix: any idea why it might suddenly have stopped picking up the new firmwares put on the FAT? |
| 10:00.18 | rahix[m] | Hm, not sure ... I'd guess some sort of filesystem corruption |
| 10:03.17 | pippin | hm, ok - busy with something else for a bit then I'll try formatting it |
| 10:13.02 | *** join/#card10badge msvb-mob (~msvb-lab@monero/hardware/michael) |
| 10:20.15 | Rahix | Try running fsck first, maybe that can help ... |
| 10:29.10 | pippin | it removed a dirty bit, but no change |
| 10:36.02 | pippin | hm nope, and a new file-system didn't fix it either |
| 10:39.35 | *** join/#card10badge LostInWeb (~quassel@2a03:4000:15:1f2::9) |
| 10:41.34 | pippin | hm, it was the crc of my new card10.bin that was amiss |
| 10:43.02 | rahix[m] | Huh, how did that happen? |
| 10:44.18 | pippin | and - since I recopied it over from my build dir again, it was not flash corruption |
| 11:04.06 | pippin | hm, trying to pass various other bytes after an LCD_WriteReg(0x36) does not seem to alter how this display renders its internal framebuffer |
| 11:06.13 | pippin | nor after the LCD_WriteReg(0x29); (which is the command to turn the display on) |
| 12:13.11 | pippin | Rahix: l0dable with working proof of concept glyph caching https://pippin.gimp.org/tmp/ctx.elf |
| 12:17.56 | *** part/#card10badge smyds (~smyds@160.ip-51-83-99.eu) |
| 12:30.34 | rahix[m] | I'll try it out once I'm back home! |
| 12:31.04 | rahix[m] | Hmm, so we'd need to reset the display entirely? |
| 12:34.06 | pippin | my current guess is that the 0x36 command is a no-op on this display |
| 12:38.56 | *** join/#card10badge fluepke (~computer@voyager.luepke.email) |
| 12:44.09 | *** join/#card10badge fluepke (~computer@voyager.luepke.email) |
| 12:44.10 | rahix[m] | This is also possible ... |
| 12:45.20 | *** join/#card10badge fluepke (~computer@voyager.luepke.email) |
| 12:46.35 | *** join/#card10badge fluepke (~computer@voyager.luepke.email) |
| 12:47.32 | *** join/#card10badge mmu_man (~revol@vaf26-2-82-244-111-82.fbx.proxad.net) |
| 12:48.08 | rahix[m] | q3k & msgctl, you two had some code for asynchronous display updates with DMA. Is that online somewhere? |
| 12:48.20 | q3k[m] | Uh |
| 12:49.53 | q3k[m] | https://git.card10.badge.events.ccc.de/q3k/firmware/commit/cf5ae77aec342d291f36a34e9b90407bbc8936db |
| 12:52.12 | pippin | one experiment I did, that sometimes is worthwhile and sometimes not - is : https://pastebin.com/WkfUJYd4 |
| 12:53.18 | q3k[m] | doesn't that has visibly collide? |
| 12:53.47 | pippin | a better hash might be worthwhile - but it does not tend to collide |
| 12:53.55 | q3k[m] | *that hash |
| 12:54.28 | q3k[m] | i would think a better way here would to have a dirty rectangle mechanism |
| 12:54.29 | pippin | it speeds up things with tiny changes | but of course slows down some where everything changes |
| 12:54.34 | q3k[m] | when dealing with immediate mode graphics |
| 12:55.11 | q3k[m] | ie any time a graphical method is called, calculate the affected bounding box in the framebuffer, and either coalesce that into the previous dirty bounding box, or keep multiple if they don't overlap |
| 12:55.13 | pippin | this is also the solution used to speed up ILI9xxx displays on RPI, where pushing pixels over SPI is much slower than touching the in-ram buffer |
| 12:55.22 | q3k[m] | with a max of like 4 dirty bounding boxes in parallel |
| 12:55.44 | q3k[m] | and then use those bounding boxes at flip time to determine which scanlines need to be sent out |
| 12:55.52 | q3k[m] | heck, even not dirty bounding boxes, just mark scanlines as dirty |
| 12:57.39 | pippin | it is outside the domain of what I'm hacking on though and in most cases it is my drawing code and not the upload which is slow :] |
| 13:00.04 | pippin | q3k[m]: this is for speeding up the case where drawing might have touched many pixels - they've been recomputed, but the hashes keep the same scanlines from being reuploaded |
| 13:20.34 | pippin | not worth it with this hardware, i suspect asynchronous upload and double buffering is better in almost all scenarios and worth the memory |
| 13:41.30 | *** join/#card10badge theAntimon (~matze@p54B09205.dip0.t-ipconnect.de) |
| 14:02.38 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 14:06.35 | *** join/#card10badge theAntimon (~matze@p54B09205.dip0.t-ipconnect.de) |
| 14:14.25 | *** join/#card10badge DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 14:52.25 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 14:52.36 | *** join/#card10badge theAntimon (~matze@p54B09205.dip0.t-ipconnect.de) |
| 14:53.11 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 14:53.46 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 14:54.29 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 14:56.11 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 14:57.40 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 14:58.19 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 14:59.11 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 14:59.51 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 15:00.42 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 15:15.41 | *** join/#card10badge erlehmann (~erlehmann@46.114.33.128) |
| 15:25.05 | *** join/#card10badge count (count@orbit.flatline.de) |
| 15:41.55 | *** join/#card10badge theAntimon (~matze@p54B09205.dip0.t-ipconnect.de) |
| 16:26.25 | *** join/#card10badge frigginglorious (~Thunderbi@71-95-76-86.dhcp.ftwo.tx.charter.com) |
| 16:30.46 | *** join/#card10badge Stormwind_mobile (~Stormwind@dslb-002-206-218-106.002.206.pools.vodafone-ip.de) |
| 16:36.10 | *** join/#card10badge theAntimon (~matze@p54B09205.dip0.t-ipconnect.de) |
| 16:40.55 | *** join/#card10badge kloenk (~quassel@mail.kloenk.de) |
| 16:45.41 | *** join/#card10badge kloenk (~quassel@mail.kloenk.de) |
| 16:53.26 | Stormwind_mobile | Is there already some kind of GUI framework? To make more complex watchfaces easier to design and use? |
| 16:55.00 | Stormwind_mobile | Also, I feel like someone should give a talk about the inner workings of card10. Something like the "ultimative ($system name) talk". I remember some about the gameboy, the C64, the Apollo guidance computer,... |
| 16:55.51 | Stormwind_mobile | Digging down deep into the hardware, from historic anecdotes down to chip level bodges, and 200 slides in 50 minutes :-D |
| 17:09.22 | pippin | Stormwind_mobile: i'm working on bringing, more-or-less html5 canvas 2d context, to card10 and other microcontrollers - not really a framework; but it is a powerful drawing model |
| 17:15.48 | Stormwind_mobile | Well, I'm thinking of something prettier than plain text, without needing to learn a complete gfx library. |
| 17:17.13 | Stormwind_mobile | So that one can get a consistent UI for a little bit more complex applet. |
| 17:19.49 | Stormwind_mobile | After repeatedly forgetting medication, I'm thinking a functionality that monitors medication intake, and reminds with configurable gentlyness if the wearer forgot. |
| 17:19.49 | Stormwind_mobile | Maybe even logging those times, which in some circumstances come in handy for the next visit at the doctor |
| 17:46.46 | *** join/#card10badge Stormwind_mobile (~Stormwind@dslb-002-206-218-106.002.206.pools.vodafone-ip.de) |
| 17:47.16 | *** join/#card10badge Stormwind_mobile (~Stormwind@dslb-002-206-218-106.002.206.pools.vodafone-ip.de) |
| 18:11.38 | *** join/#card10badge msvb-mob (~msvb-lab@monero/hardware/michael) |
| 18:15.59 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 18:31.48 | *** join/#card10badge frigginglorious (~Thunderbi@71-95-76-86.dhcp.ftwo.tx.charter.com) |
| 20:09.52 | *** join/#card10badge theAntimon (~matze@p54B09205.dip0.t-ipconnect.de) |
| 20:39.00 | *** join/#card10badge fibmod (~fibmod@254.238.207.77.rev.sfr.net) |
| 21:05.19 | *** join/#card10badge Rev_Illo (~revillo@unaffiliated/rev-illo/x-3122184) |
| 22:03.39 | *** join/#card10badge Sammy8806 (~sammy@irc.sammy8806.de) |
| 22:09.15 | *** join/#card10badge erlehmann (~erlehmann@46.114.35.169) |