#timonsku np tag me when yr done if you
wispy flame
i think i frazzled it
its fast to set up
and im going to try duplicating what you have with the DSI I2C rather than wiring over to the main I2C port
scarlet brook
sounds good
wispy flame
alright well im back where i was before and still nothin but i did write down everything i changed
scarlet brook
ok! Are you on a Pi4 now?
wispy flame
yes definitely ahah
here is what i did
* run:
sudo raspi-config nonint do_i2c 0
sudo raspi-config nonint do_spi 0
sudo raspi-config nonint do_serial 0
sudo raspi-config nonint do_ssh 0
sudo raspi-config nonint do_camera 0
sudo raspi-config nonint do_hostname dsipi
sudo raspi-config nonint do_change_locale en_US ISO-8859-1
sudo raspi-config nonint do_change_timezone America/New_York
sudo raspi-config nonint do_finish 0
sudo apt-get install -y dos2unix python3 git python3-pip
python --version
pip3 install RPi.GPIO
sudo pip3 install --upgrade setuptools adafruit-python-shell
cd ~
wget https://raw.githubusercontent.com/adafruit/Raspberry-Pi-Installer-Scripts/master/raspi-blinka.py
sudo python3 raspi-blinka.py
* reboot
* add to end of /boot/config.txt
dtoverlay=i2c0,pins_44_45
dtoverlay=ICN6211
dtdebug=on
* scp ICN6211.dts pi@dsipi.local:
* dtc -@ -I dts -O dtb -o ICN6211.dtbo ICN6211.dts
* sudo cp ICN6211.dtbo /boot/overlays/
* sudo reboot
* git clone https://github.com/timonsku/Adafruit_CircuitPython_ICN6211
* pip3 install adafruit_extended_bus adafruit_circuitpython_register
* python3 examples/icn6211_simpletest.py
* (run it again)
* add "loglevel=6 drm.debug=0x14" to end of /boot/cmdline.txt
* reboot
ok cool, sounds good on paper
wispy flame
and this is the dts
scarlet brook
can you see if sudo vcdbg log msg now works?
wispy flame
it does!! 🪄
scarlet brook
and this is the dts
looks good
wispy flame
pi@dsipi:~ $ sudo vcdbg log msg
003460.900: arasan: arasan_emmc_open
003461.070: arasan: arasan_emmc_set_clock C0: 0x00800000 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 400000 max: 400000 delay: 5
003565.829: arasan: arasan_emmc_set_clock C0: 0x00800000 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 400000 max: 400000 delay: 5
003565.915: arasan: arasan_emmc_set_clock C0: 0x00800f00 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 390000 max: 400000 delay: 5
003584.817: arasan: arasan_emmc_set_clock C0: 0x00800f06 C1: 0x000e0207 emmc: 200000000 actual: 50000000 div: 0x00000002 target: 50000000 min: 0 max: 50000000 delay: 1
003673.158: brfs: File read: /mfs/sd/config.txt
003674.164: brfs: File read: 2142 bytes
003696.008: HDMI0:EDID error reading EDID block 0 attempt 0
003697.025: HDMI0:EDID giving up on reading EDID block 0
003709.023: HDMI1:EDID error reading EDID block 0 attempt 0
003710.037: HDMI1:EDID giving up on reading EDID block 0
003712.103: brfs: File read: /mfs/sd/config.txt
004524.070: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
004527.128: *** Restart logging
004527.147: brfs: File read: 2142 bytes
004532.678: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
004533.694: hdmi: HDMI0:EDID giving up on reading EDID block 0
004538.738: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
004539.756: hdmi: HDMI0:EDID giving up on reading EDID block 0
004539.772: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
004544.812: hdmi: HDMI1:EDID error reading EDID block 0 attempt 0
004545.830: hdmi: HDMI1:EDID giving up on reading EDID block 0
004550.869: hdmi: HDMI1:EDID error reading EDID block 0 attempt 0
004551.883: hdmi: HDMI1:EDID giving up on reading EDID block 0
004551.901: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
004551.917: HDMI0: hdmi_pixel_encoding: 300000000
004551.929: HDMI1: hdmi_pixel_encoding: 300000000
004552.272: kernel=
004559.211: dtb_file 'bcm2711-rpi-4-b.dtb'
004565.554: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
004565.572: Loaded 'bcm2711-rpi-4-b.dtb' to 0x100 size 0xcd71
004578.833: brfs: File read: 52593 bytes
004597.727: brfs: File read: /mfs/sd/overlays/overlay_map.dtb
004671.693: brfs: File read: 2347 bytes
004675.769: brfs: File read: /mfs/sd/config.txt
004676.175: dtparam: i2c_arm=on
004684.827: dtparam: spi=on
004693.080: dtparam: audio=on
004697.651: brfs: File read: 2142 bytes
004725.030: brfs: File read: /mfs/sd/overlays/vc4-kms-v3d-pi4.dtbo
004786.367: Loaded overlay 'vc4-kms-v3d'
004936.491: brfs: File read: 3913 bytes
004948.668: brfs: File read: /mfs/sd/overlays/i2c0.dtbo
004964.051: Loaded overlay 'i2c0'
004964.064: dtparam: pins_44_45=true
004991.112: brfs: File read: 1785 bytes
005019.922: brfs: File read: /mfs/sd/overlays/ICN6211.dtbo
005037.387: Loaded overlay 'ICN6211'
005123.697: brfs: File read: 2802 bytes
005127.030: brfs: File read: /mfs/sd/cmdline.txt
005127.081: Read command line from file 'cmdline.txt':
005127.095: 'console=serial0,115200 console=tty1 root=PARTUUID=90c24bc2-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles loglevel=6 drm.debug=0x14'
005241.217: brfs: File read: 175 bytes
005974.146: brfs: File read: /mfs/sd/kernel8.img
005974.165: Loaded 'kernel8.img' to 0x80000 size 0x7d6bd0
007144.910: Kernel relocated to 0x200000
007144.924: Device tree loaded to 0x2eff2800 (size 0xd780)
007152.223: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
009236.671: vchiq_core: vchiq_init_state: slot_zero = 0xcf000000, is_master = 1
okay so its at least happy with the icn overlay thats good
only thing I can think of that there might be some mutual exclusivity for DSI panel and HDMI? Have not tried that yet together
wispy flame
yeah altho why is my backlight not on
scarlet brook
huh yea thats suspicious, it always comes on for me no matter what
wispy flame
ok i power cycled the ICN board who knows
im going to redo it anywyas, let me re-run the config
AHA
AHAAAAAAAAAAAAAAAAAAAAA
🪩
scarlet brook
yay 😄
wispy flame
HEK YEZ
scarlet brook
nice!
scarlet brook
depending on whether you boot to console or Desktop is may or may not be a fully stable image. I found the clock config from the example as it is in the repo right now is not fully stable in all situations (but happy with console colors at all times)
scarlet brook
so def. some tuning there to do
yea its odd, sometimes I come back an hour laters and its fuzzed out
wispy flame
ok ill let it run
scarlet brook
and can be "repaired" by opening chrome
wispy flame
that might be a linux thing
maybe its trying to screensave?
alright so next step is i should redo the icn board, because the atsamd is annoying,
scarlet brook
fairly certain its clock related, lemme check I think I made a video of a more immediate glitch
scarlet brook
scarlet brook
it will vary by panel too
for sure yea! Getting a good understanding of how to configure the clock and what it doesn't like will help a lot I think
wispy flame
and or hsync polarity
scarlet brook
that could be!
wispy flame
the clock itself...tbh...its pretty chill about variation
scarlet brook
its pretty random values atm
wispy flame
but if the porches and polarity dont match the panel setup the driver cant sync
which is why i wanted you to make it easy to adjust 🙂
OK now we r cookin' - so theres a few SIDE QWESTS here
scarlet brook
the ICN itself seems a bit picky, it seems you have to be careful about the max output PLL (according to the Linux driver) unfortunately the datasheets I have give zero guidance there
scarlet brook
OK now we r cookin' - so theres a few SIDE QWESTS here
sounds good, whats next 🙂
wispy flame
well, you can pick your poison
- look at the DS for the panel you got, to determine the desired porch/vsync/polarity values
- try generating a config for a 4.3" 480x272 (wierd shape i know)
scarlet brook
both sound good, the latter I had going a few days ago but not really tuned at all, would have to check the DS for that too
scarlet brook
for 3) I would probably need panels, do you have some in store that you are eyeing at?
ah I do actually have some 240x240 round display from the CCCamp badge, lemme check if they take DPI too
wispy flame
i dont stock any but theres tons on aliexpress or eastrising or other kool-beans-tft-sellers
240x240 is probably SPI
scarlet brook
it is yea but often they support a couple transports
wispy flame
- see if we can do resistive or capacitive touch via the DSI I2C
scarlet brook
ah yea, my 4.3" has resistive touch, could use that for a first test if those signals are connected on the breakout?
wispy flame
oh interestng the pi screen zonkedout
like its been e few minutes
let me see if connecting a mouse helps
scarlet brook
huh yea screensaver might be a good bet
wispy flame
@scarlet brook yeah so what id really dig is if we could use a TSC2007 to read the resistive TS
the q is if the ICN shares the bus
i think it cant
scarlet brook
yea its a bit weird that it drowns out the bus like that
wispy flame
yeah its the screensaver
scarlet brook
but if we keep with the plan of having a config mcu on there we could isolate it from the pi
wispy flame
it should change the DE pin to low to turn off the screen but it doesnt
scarlet brook
yeah its the screensaver
ok nice
wispy flame
yeah i think for now you could have the TS on the 'main' i2c port
just for your prototyping
scarlet brook
it should change the DE pin to low to turn off the screen but it doesnt
yea for that it would need to be a full driver, right now we just kinda hijack another one and the control signals go to nowhere
scarlet brook
yeah i think for now you could have the TS on the 'main' i2c port
yea makes sense
but yea there is definitely some decisions to be made of what the nicest setup would be from a driver perspective. Either hi-jack the Pi Touchscreen driver, which is a bit hacky but gives bootloader screen time without asking them for firmware changes.
Or use or customize the existing ICN driver to our needs.
wispy flame
i really dont want to have to compile a kernel module :/
scarlet brook
yea in the custom case we would need to submit a PR to the Pi Kernel to make that usable
wispy flame
the icn kernel driver does i2c configuration right?
are we using this for the display? https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/chipone-icn6211.c
scarlet brook
In theoery but I'm not sure it properly implemented it, I know I got stuck there a bit last year when I tried to get that working.
scarlet brook
are we using this for the display? https://github.com/torvalds/linux/blob/master...
right now we use the Toshiba bridge driver as the ICN driver is not currently included in the Pi Kernel, that requires compiling the module and loading it
wispy flame
no waaay
scarlet brook
ah you wouldn't need to compile a kernel but keeping up with releases for custom modules is not great either
wispy flame
they didnt include it? ok
scarlet brook
yea.. haha they are doing the same hack we are doing atm
wispy flame
i get it, we're just sending the dsi data as if it were a toshiba
i think they are usint a toshiba!
scarlet brook
because they don't need the control signals from the toshiba driver as they have their own control interface via their MCU
scarlet brook
so that bridges the kernel signals etc. which I guess makes things easier if you want to support more displays down the line or make other hardware changes that stay backwards compatible
wispy flame
well i really do not want to have to deal with kernel updates. it sux to compile and of course on a pi zero its also unbelievably slow
so im ok with reusing toshiba's dsi driver
can you see if TSC2007 is in the raspi kernel, i know its a module
wait no i alreayd checked, so ignore me
like i could use an RP2040 to be a touch/backlight/icn massager but it feels sorta like overkill?
but it would provide usb which is universal
its a tough decision to make :/
welp i think ill go with an attiny for a massaging processor and maybe add a dpdt so you could use the DSI I2C if desired
can always go bigger
so yeah, i think next up, try other resolutions and/or the TSC2007 for resistive touch
https://www.buydisplay.com/4-3-800x480-ips-tft-lcd-module-all-viewing-optl-touchscreen-display has some smaller screens with captouch too
i can have the attiny look for the vsync pulse to determine when to enable the backlight
scarlet brook
its a tough decision to make :/
yea! I guess its a cost factor. From a flexibility perspective I do see merit in that Pi Touchscreen approach. You could have one flexible driver that you submit into the Kernel and don't have keep up with and support things like new touchscreens or displays via the intermediary config MCU
Pi is usually pretty open in getting things into their kernel, we wouldn't have to upstream
Or not do that at all and stick with whats there altho limiting with resolution settings
wispy flame
right, especially for things like rotation/calibration - the x11 config tools are way less bad than dorking with a microcontroller
scarlet brook
my main headache is that currently you can't really define a display outside of the kernel modules, maybe that changed or maybe there is something I haven't found yet but outside of that kernel bootflag that overrides the DSI resolution directly a normal compositor config doesn't change anything like it does with HDMI etc :/
wispy flame
so the resolution is fixed at 800x480? in the toshiba module or...?
scarlet brook
which is why I found a custom kernel module an attractive idea where you could just ignore the current collective wisdom of how panels should be configured and just hack something into device tree or so, while limiting you could likely define a config for most more usualy DPI displays. I think the main issue why it never happened in mainline is because it gets too complex if you do that approach with every type of panel out there
scarlet brook
so the resolution is fixed at 800x480? in the toshiba module or...?
kind of, the toshiba driver is resolution agnostic, it acts kind of like the "PHY" for the panel-simple driver and in that driver you currently define your panel resolution, porch etc
or actually not 100% sure if the pi display only goes through that now, they def. had a fully custom kernel module for a while
right so in mainline linux its still the old setup with the custom driver.
In the pi kernel its now defined in panel-simpel:
https://github.com/raspberrypi/linux/blob/431319d91b8584c9f28b195ab9a97d7e78905aeb/drivers/gpu/drm/panel/panel-simple.c#L3240-L3263
bridges like the ICN or the Toshiba one are kind of special citizens in DRM, I'm hazy on it but topology wise they sit between an actual display driver (panel-simpel in this case) and the actual physical display output (DSI driver)
wispy flame
hi hi, pardon my slight disappearance the baby woke up 🙂
scarlet brook
no worries 🙂
wispy flame
I will research this a little bit more when I'm at my computer next however, feel free to go with any of those side quests mentioned earlier. Also, please invoice for the work done so far you can email Stella and CC me.
scarlet brook
sounds good! 🙂
and yea I think the whole Linux side of it needs a bit of thinking, wouldn't rush into it
getting late for me too, will be off now.
If there is anything I can help with on understanding the DRM stuff let me know, it has definitely driven me mad last year
wispy flame
oh man there is such gooood stuff here https://jlcpcb.com/parts/2nd/Communication_Interface_Chip_UART_485_232/Video_Interface_ICs_79491
scarlet brook
oh wow, thats definitely a fairly new category. I was looking for that Toshiba HDMI to DSI IC in the past and it was really tough to find even on taobao.
wispy flame
i know fr right? also the ADI HDMI -> TTL with I2S is like $4!! usually $8-10
maybe we will attack the HDMI to MIPI next, there are some totally cool and wacky displays that are MIPI only
what a wierd chip https://jlcpcb.com/partdetail/VlsiSolution-VS23S010DL/C486311 - probably custom made for their TFT driver boards
(for later ref)
scarlet brook
maybe we will attack the HDMI to MIPI next, there are some totally cool and wack...
that would be cool! I was kinda trying to get docs for those ICs in the past but most of those companies, especially Toshiba, just don't write you back unless you are a really big company.
scarlet brook
what a wierd chip https://jlcpcb.com/partdetail/VlsiSolution-VS23S010DL/C486311 ...
oh yea they make some funky stuff, I found a chip from them in a portable projector that was essentially a HDMI to DPI converter but with a fairly beefy GPU that can decode h264 at 720p and a tiny micro controller to setup the GPU with your UI
wispy flame
well, having them respond isnt so great either. we emailed lontium and they wanted us to fill out an nda - but...we're smart cookies so we'll figure something out 🙂
wispy flame
also fyi if you have a pudn accounts, sometimes we can find stuff there, its middling quality
scarlet brook
oh didn't know they are back, was sad when their site was taken down
hrm but looks like my old account doesn't work anymore and it requires a Chinese phone number apparently
scarlet brook
looks like it popped back online 3 months ago, a bit suspicious 😄
wispy flame
@scarlet brook could be a honeypot 🙄
ok i ordered a plethora of wierdo display samples from https://shop163014679.taobao.com/ and https://shop224067187.taobao.com/ and ill get you one of each once they arrive. lots of unusual resoliutions
scarlet brook
nice!
wispy flame
wispy flame
see also 6by9s (raspi employee) pr for the dsi configs for. various rez…we can mimic that and it should be accepted 🤔
scarlet brook
ah yea I had a read through that issue, a bit odd that Pi engineers spend that time instead of Waveshare but oh well 😄
but yea I don't think having anything we make be accepted into the Pi kernel should be difficult, they are usually not that picky, tons of third party panel device tree overlays already in there that aren't present in upstream Linux
scarlet brook
its certainly a third approach, just submitting configs for every panel we want to support, it just means that it can take a while until people can make use of the panel without a hassle. Which is why I was looking into ways to allow for runtime configuration, which is definitely a harder nut to crack but I think for this use case of bridge ICs where you don't have ever different and complicated DSI configs to do, all you really need to change is adding a new mode.
Something I wanted to look into are the cmdline overrides. As video=DSI-1:480x272@60 f.e. does in fact force the DSI resolution I'm wondering if the edid override of the drm kernel boot flag can also be used for DSI or if the driver needs to specifically support edid somehow. Providing your own edid could be turned into a fairly user friendly workflow, it just needs to be placed into /lib/firmware and via the drm.edid_firmware flag
but in any case, if we were to submit our own driver/customize the upstream icn6211 I think user provided EDID would be a nice approach to load custom display timings at runtime. I can't imagine it being all too crazy to implement, the systems are there, if it doesn't already work it might just be a matter of a drm_driver flag
wispy flame
lets do both: try to make it work on runtime and also submit a PR
raspi does do releases often
we also do sometimes compile out of tree, altho aren't huge fans of it...
it works fine, but of cousre when folks upgrade it stops working
i wonder if we could ask it to get the EDID from DSI I2C 🤔 like HDMI, not sure...
but we have a few options
scarlet brook
i wonder if we could ask it to get the EDID from DSI I2C 🤔 like HDMI, not sure...
afaik its not a supported by DSI in any way but I'd say we could totally implement it as a custom function of our driver.
Tho do you see a benefit of it coming from an external source vs being loaded from OS disk? Or do you envision EDID being generated on the fly from the ICN config?
wispy flame
yeah like just thinkin' - there's the HAT EEPROM that loads the display tree overlay automagically. tbh not sure how that works but like, wouldn't that be cool if it did 🙂
scarlet brook
oh yea, I mean you need to have a power connection anyways, that could justify a mini HAT formfactor
You include the dtbo in the eeprom, so yea technically that would be a very seamless experience. I do wonder a bit how they handle backwards compatibility with the device tree though. Sounds a bit icky to have your overlay be so static to a degree, could have some bit rot over the years
but sounds like we have a rough idea where we want to head on the Linux side.
What should I prioritize? Keep working on the side quests for now or flesh out our Linux side concept and do an MVP there?
wispy flame
@scarlet brook yah sorry im rambling. getting a 'neatened up' DTO which has the captouch overlay and/or restouch TSC2007 driver probably easiest thing to do next?
im weirded out that theres no IRQ line, do the dsi displays out there now just like, spam i2c reads?
after touch we can look at backlight control
then we can start a fork of the raspi linux disti where we start defining our panels and try to get the DTO upstreamed
scarlet brook
<@375455651050160130> yah sorry im rambling. getting a 'neatened up' DTO which h...
sure can look into that first, tho can't verify until I have hardware, don't think I have a board here with that IC
ah tho maybe the DPI Kippa? need to check
scarlet brook
then we can start a fork of the raspi linux disti where we start defining our pa...
no need to do a fork of the distro itself, would just be a kernel side thing.
In any case that we start with we would need to modify a kernel driver though, a overlay alone would not be enough. If we just define a panel config we would have to add each panels definition to the panel-simple driver
wispy flame
scarlet brook
ah nice 🙂
wispy flame
ok let me see
so ill get these boards probably next week
do you have any captouch TFTs
they all use the same fam of chips
well, mostly. its either goodix or focaltech
scarlet brook
I have a few bare cap touch screens and a couple bonded ones yea
just a heads up I'm traveling to cccamp on the 10th and back on the 21st.
I plan to take some stuff with me so can probably still work on stuff in the first few days but 14-19th I'm probably not available.
wispy flame
np, just waiting on hw now
fyi re:smearing effect https://github.com/raspberrypi/linux/issues/5152#issuecomment-1655464658
i guess while we wait you could begin the panelsimple.c fork
and create a combo dsi screen + ctp dto
wispy flame
wispy flame
@scarlet brook hiya ^ expected to be delivered monday
if you place an order using the same instructions as last time i will send you some square displays and the new ICN breakouts
scarlet brook
ah cool, will do that later today!
Sorry for little communication, had a lot going on the past days.
scarlet brook
fyi re:smearing effect https://github.com/raspberrypi/linux/issues/5152#issuecom...
ah interesting!
scarlet brook
i guess while we wait you could begin the panelsimple.c fork
Yea that make sense, I'll let you know how far I get before leaving for cccamp. It's likely that I will only get the new board once I'm back.
wispy flame
all good!
wispy flame
@scarlet brook ok sending you a variety of displays. unfortunately the captouch displays i have use an 8-pinFPC :/
but maybe you can find an 8-pin FPC breakout locally
the square display has the ctp 'built in'
scarlet brook
awesome, and yea I have dozens of FPCs here, should have an 8 pin that I can solder to a breakout
that should do it
wispy flame
oh great - ok cool thankya! i included a few options to try out with various resolutions including a 480x800 display (not 800x480!)
id still do the rectangle 800x480 displays first - the odd shaped displays get complex fast with the SPI init code 😢
scarlet brook
oh yea that sounds weird, if display do stuff like that it might make sense to have stuff like that live on the local MCU to abstract that away from Linux
wispy flame
yes the SPI programming part is gonna be done by an attiny1616 which i placed onboard
it can also do backlight control
scarlet brook
nice
wispy flame
to program it you will need a UPDI cable, but they're easy to make with any USB-serial converter and a 4.7K res
wispy flame
hihi @scarlet brook just checkin if you are back from summer slumber camp 🙂
scarlet brook
oh didn't get a notification on Desktop but yes 😄
scarlet brook
caught a proper infection from camp (not covid luckily), getting better though, think I should be fit for getting back to work next week
wispy flame
@scarlet brook okidoke
wispy flame
@scarlet brook hey wanna see something cool
scarlet brook
always!
wispy flame
@scarlet brook sorry went to get a snak
i used chatgpt 4 to convert one of those annoying init code lists to the right format
(for the library im using on arduino, but obvs could be adapted for us later)
scarlet brook
i used chatgpt 4 to convert one of those annoying init code lists to the right f...
sweet!
I have yet to try the conversational version of Copilot which as far as I understand is meant for stuff like that but more code focused than the general purpose GPT4.
Its really useful for these more menial tasks.
wispy flame
yeah this is "code analyzer" beta
scarlet brook
ah nice
scarlet brook
def. new to me! I had cancelled my subscription to GPT4 so haven't been keeping up too much.
I wonder how it compares to the Github Copilot one or if its the same feature with different interface.
wispy flame
interesting, i havent used any copilots 😓 maybe i should!
scarlet brook
https://docs.github.com/en/copilot/overview-of-github-copilot/about-github-copilot-for-individuals
its essentially gpt backed auto complete, there was a bit of controversy because it seems to have used github as the training data.
Its quite a nice productivity tool, esp. when you write repeated structures, it ususally picks up on context quite well.
It doesn't write your application for you but def. helps with the more typing heavy stuff where normal auto complete would fail.
wispy flame
id be totally fine if it was just trained on my code 😄
scarlet brook
heh, its definitely subset of it!
wispy flame
@scarlet brook ok im going to zz but you should have various hardwares
do you need a refresher of where we're at
scarlet brook
yes I have the package(s) with bunch of displays and the new PCBs.
In my head the next step would be to get a modified simple-panel going with some timings of our own displays added and then creating a device tree overlay that enables touch (and or modify driver for touch if necessary) and display.
From there I could start working on the actual goal of creating a driver that would allow for runtime configuration of panel characteristics on the Linux side which we would then "upstream" into the Pi Kernel once in a state that we like so that it becomes a default part of the RPi OS.
wispy flame
@scarlet brook yah!
scarlet brook
for the run time configurable driver I feel like the most unix way would probably be to use EDID there. It's more than we need but its an existing way of doing things and providing EDID as files is an established thing.
The format is also fairly extensible with vendor blocks so we wouldn't be locked into what the format provides if we see more stuff that we would want to provide with a panel definition like f.e. the ICN config.
the panel-simple driver also already does some edid stuff but haven't figured out yet in which scenarios, it seems to look if there is a DDC bus available, so might be a matter of the lower level driver offering that or not.
wispy flame
@scarlet brook yes interesitng idea - lets figure out the EDID later - EDID structure is known but also, sucks tp generate
(especially extended EDID)
fyi i have some 4" 720x720 square screens that...bless 'em... do not require SPI configuration. they just pop right into RGB mode with all right settings. so that might be a good display after 800x480 is done
scarlet brook
<@375455651050160130> yes interesitng idea - lets figure out the EDID later - ED...
That is true, I’m still reading up more on what other ways exist. There is also a canonical way to define strictly timings in DT, which is easier to handle and write in general but also requires a compilation step and feels like for an end user could be more confusing but it depends on the interface, I think any solution would need some form of web UI or cli utility to make this truly accessible and then only needing to place the resulting file into a specific spot and you’re good to go.
EDID has the benefit that we have, at least in theory, the ability to define in our driver a DDC interface that reads in EDID data from our comms MCU so that we can use whatever interface we prefer for our config and once configured its plug and play on any other Pi that has the latest OS that includes our driver. Which I think would be a really neat UX. On Adafruits end that could also enable selling pre-configured kits where there is nothing to do for the user than to plug it into their Pi.
you can define a custom DDC interface that is not DDC compliant I2C bus, which can be used to send simplified data from MCU to driver and build the EDID struct on the host side instead of the MCU which would simplify the firmware there and the primitives to create EDIDs from just timings are already in Linux
essentially the data source can be anything but to DRM is looks like a normal DDC interface that plugs into the existing infrastructure
(not jumping ahead, just thinking about the direction after we played with the existing things to verify function)
wispy flame
@scarlet brook ok yah! im just ocntinuing to go through various funky displays to work out the init and timing data. ready to hack when you are around!
scarlet brook
still taking it slowly, recovery dragging out a bit doing little blips throughout the day atm
currently looking into touch drivers
scarlet brook
ah @wispy flame can you send me the eagle files for the new boards?
wispy flame
ok almost all the funky shape displays use FT6336U
scarlet brook
ah cool that would have been the next question 🙂
wispy flame
@scarlet brook we did get circuitpython working with rgb support on the esp32-s3 so i can quickly test out different init/syncwidth setups
datasheet, but im like 99% sure linux has a driver
scarlet brook
<@375455651050160130> we did get circuitpython working with rgb support on the e...
nice!
scarlet brook
datasheet, but im like 99% sure linux has a driver
looks not in mainline but there seem to be some out of tree drivers floating around
ah ok no looks like it got unified into this one https://github.com/torvalds/linux/blob/master/drivers/input/touchscreen/edt-ft5x06.c#L1501
confusing naming
small silk legend flip 🙂
scarlet brook
TSC2007 is working, both in isolation on its own bus and on the same bus as the ICN
guess the ICN doesn't interfere much after all beyond just being a little bit too responsive on all addresses
scarlet brook
@wispy flame if you got the datasheets for the displays floating around, those would be handy. Esp. for the square one. No rush tho
cap touch on the square one also working!
wispy flame
hihi
sorry - dont forget to email me if you need something fast (im not always on discord)
i dont recall which ones i sent you >.<
can you tell me the part numbers on the back?
scarlet brook
all good and will def. email if its more urgent!
will collect pns later
wispy flame
@scarlet brook ok im around now if you want something
scarlet brook
ah nice just got back to things, lemme write down the part numbers of the panels
wispy flame
@scarlet brook 👍 i hope you are feeling better
scarlet brook
KD50G21-40NT-A1 some 16:9 screen with cap touch
HM040HQ-40R small 16:9ish ~3inch panel
BLU-H1239A-v01 (TL040WVS01CT) the larger square panel with cap touch
C4OZNO1-LFPC-01V2 another square panel
@wispy flame
scarlet brook
<@375455651050160130> 👍 i hope you are feeling better
yes! thanks for asking 🙂
feeling okay and made some good progress the last 2 days
wispy flame
for the KD50 (5" 800x480 can use this https://www.adafruit.com/product/1680) the captouch part let me see if i can find
is it 6 pin or 8 pin captouch
i think is it
scarlet brook
8pin
wispy flame
ok i think the outer two pins are just ground
unforch i cant find the exact DS i think this was a sample
you can maybe read the ctp chip number, probably FT5 or FT6
the FT captouch chips are all very similar, and dont usually require any calibration or firmware-init. they just start up with the x & y output
HM040HQ-40R let me look
scarlet brook
unforch i cant find the exact DS i think this was a sample
ok! yea if you are not super keen on testing it doesn't matter too much I guess. I have the cap touch going on the square one but not the display for it.
wispy flame
TL040WVS01CT i just got working with arduino, its 480x480 ST7701s
let me get you the init code
scarlet brook
and yea the focaltech ones seem to be all the same, the driver got unified into one for all the chips
scarlet brook
TL040WVS01CT i just got working with arduino, its 480x480 ST7701s
ah does it require a spi init first?
wispy flame
yes it does 😦
i tried to give you a mix of "no init" and "init needed"
ok just save those files for now
scarlet brook
thats def. an interesting case to think about
scarlet brook
ah right now I remember
wispy flame
dont worry its all a plan
ok the last one is actually the easiest
C4OZNO1-LFPC-01V2 - did i write "720x720" on the back
scarlet brook
nothing written on the back
wispy flame
the C40Z is on the fpc yeah?
scarlet brook
yea, lemme take a pic
wispy flame
np i just wanna make sure
ok that is a 720x720 with no spi init
you can just blast pixels to it
so you actually should do that one 'first'
scarlet brook
ok!
wispy flame
now i am remembering - i think i gave you 'one of each type'
i think the easiest easiest is the KD50 - its 800x480 and if you are very careful you can nip the pin #1 and pin #8 to have it fit into the 6-pin FPC
this one would require a DTO (to like, set it up and have th CTP work) but not a custom kernel driver because its 800x480.
next easiest is the 4" 720x720 - no SPI init needed either, and no CTP BUT it does have a wierd rez
scarlet brook
the KD50 I had tested in the non touch variant, would mostly need to look at the touch there
wispy flame
so a custom kernel driver PR will be required - i think we found the spot that the waveshare (?) drivers were put in by a raspi folk
to set the funky rezolution
HM040HQ-40R im a little confused why i sent that to you
let me find mine and maybe itll come to me
scarlet brook
heh
wispy flame
(in the meantime i also got a lot of samples of round and bar displays too)
did i give you the board that goes with the HM040 - it looked like this:
scarlet brook
so a custom kernel driver PR will be required - i think we found the spot that t...
right, depends on how you would like things to look in the end. One approach can be to just add some more display timings to the existing panel-simpel driver.
That one waveshare display was using a boot flag but that is a bit limited in what you can set from what I saw so gotta hope that rest of the display timings work out with what exists in the driver.
wispy flame
display timings yeah...some of these screens are a little picky about the pclk
most are pretty flexible
scarlet brook
from my pov the nicest UX would be to have "custom" driver that makes use of the EDID system and have all data for the driver be read via I2C from the MCU on the ICN board
wispy flame
sure, we could fake it with the Attiny acting like a 24LC
scarlet brook
the only thing that really needs to be written there is enabling setting an EDID timing in the kernel
wispy flame
or just toss a 24LC on there
scarlet brook
sure, we could fake it with the Attiny acting like a 24LC
or that, we have two routes, either be DDC compliant or we could employ the custom DDC bus API and use the I2C bus in the way we like it and only send the data we need
wispy flame
and ill have the ICN dev board for sale, for trying out new displays. so even if we go with an EDID, we still will need 'step by step' instructions for configuring different screens
scarlet brook
being DDC compliant could have the option to work with panel-simpel as is but would need to verify that, its not really well documented
wispy flame
that i dont know - but def if we can have an EEPROM like the HAT configuration...that would be very nice!
scarlet brook
yes! that would be the last piece there.
What had in mind would mean that you could configure a board once via I2C, for that you could maybe even use any CPY board with a Stemma QT.
Once the config is transferred, in theory, you could plug that into an RPi that runs the newest OS and it would just work without needing to do anything at all on the Pi side.
wispy flame
if its supported in the 'mainline pi kernel' im all for it. i just dont want to maintain kernel stuff because im not very good at it
scarlet brook
oh absolutely, I think that should not be an issue to get that in there
wispy flame
ok if you have that funky board above, you can do the HM040 - this is another wierd one in that it is 480x800 not 800x480 aaaand it need spi init
so id do that one last last
scarlet brook
ok if you have that funky board above, you can do the HM040 - this is another wi...
I do have that one yes
wispy flame
ok great. whats your plan for next thing to hack
scarlet brook
from my side it depends a bit on what your priority would be. Captouch and resisitive touch I checked out and it works down to the desktop level, wasn't much needed apart from figuring the DT setup out. There is def. tuning needed depending on the touchscreen and underlying display of course.
If you like that architecture of having "plug and play" solution that can be "mainlined" I think that would then what I would sketch out now. This will be a good chunk but to me the ultimate goal at the end so that there is no need to constantly fuzz with getting new panel definitions and hacks upstreamed and that that data can instead be controlled via the config that is programmed to the board.
That is of course more upfront work but more flexibility down the line.
Modifiying existing stuff with panel definitions and writing a DT overlay would be faster and could get things out the door now but would be more ongoing work on the Pi side then if you plan on having lots of different panels down the line or if people wanna bring their own panel in.
Maybe it would make sense if I make a little diagram there for communication? Feel like there is quite a few pieces there to keep in mind.
I can also make sure first that all the panels play okay with the ICN before embarking on that if thats more important to figure out for now.
wispy flame
Hold on that’s a lot to read 🙂
well, the edid idea is very interesting… But we have to determine whether it’ll work, and whether they will take the upstream PR. So I think it’s worth spending a few days checking with the pi maintainers and feeling out whether they would take such a pull request and/or if it would even work. if so, I will have to respinwith a 24lc but that’s not a big deal and we can just connect manually for now
scarlet brook
totally onboard there, let me make a sketch that outlines the architecture, I think we should not need a 24lc in theory but it would be more firmware work for sure to "emulate" that for the HAT poke at boot.
I can ping the Pi people in the meantime how open they are to new drivers and if there is anything they wanna see or not see.
wispy flame
soudns good. tbh a 24lc is so cheap and is easily re-programmable if folks need, ill probably just add one - a 5-pin SOT-23 is like 15 cents
scarlet brook
totally fair yea!
we might wanna have the ability to re-program that from the MCU. F.e. when employing a touchscreen we would want to present a different dt overlay blob
wispy flame
wouldnt the DTO be in the EEPROM? how would the microcontroller present the DTO
right now my thinking is the mcu does the SPI in it and an i2c-> pwm backlight control
scarlet brook
yes that would sit on the eeprom, thats why I mean being able to flash the content of that would be good, currently I see the MCU as the source of truth for any specific display config that is then spat out to the relevant bits on the Pi to make sure it loads and configures the right thing.
On the DT side I would either see that it emulates the EEPROM or during the MCU config process it writes that data to the EEPROM once and then the Pi reads the EEPROM instead of the MCU emulating it.
wispy flame
you could reprogram the eeprom pretty easily by updating the config to expose the i2c interface
then writing to addr 0x50?
the MCU you'd have to wire up RX & TX pins from the pi's UART - not terribly hard but UPDI kinda works best with a USB adapter
scarlet brook
you could reprogram the eeprom pretty easily by updating the config to expose th...
the last bit I don't quite understand, what do you mean with that? 🙂
wispy flame
the 24LC is going to be connected to the DSI I2C port so the pi can read the eeprom data on boot to configure the graphics driver however you end up choosing it to work
if someone wants to 'write' to it, the could rmmod the kernel driver, edit /etc/config.txt to expose the DSI's I2C port (its like I2C-3?) and then write to it with any EEPROM command line writing tool
(i think)
scarlet brook
the 24LC is going to be connected to the DSI I2C port so the pi can read the eep...
ah that doesn't work (I think). The HAT EEPROM read only happens on those ID_SC/ID_SD I2C pins on the 40pin header
scarlet brook
if someone wants to 'write' to it, the could rmmod the kernel driver, edit /etc/...
but that would still be an option
let me doodle a few things up, I think I glossed over some things in my description, it's quite a few moving pieces
wispy flame
@scarlet brook ooh well, these wouldn't be a HAT
so does that mean we cannot use this system? i kinda want it to only use the DSI cable 🤔
scarlet brook
we can still largely use it, its essentially two seperate things that are happening. I was mostly trying to figure out how to keep the interaction for the user to a minimum so that they don't have to set a bunch of stuff to make a panel work and only interact with one thing that sets everything.
we have two things to solve, one is telling the Pi Kernel driver what display timing to use, for that we can employ the DSI I2C just fine.
But for our driver to be loaded at all we need to set a DT overlay. That can be done via config.txt or via a HAT eeprom.
Now that I'm thinking about it I do wonder how the Pi touch display does it. I think they have some hidden bootloader magic there for their own display but thats def. worth double checking because I'm def. with you there, only using the DSI cable would be much nicer.
wispy flame
telling people to edit confif.txt isnt so bad
scarlet brook
for sure, its more the cherry ontop really
wispy flame
i do think there is Magic
scarlet brook
coming a bit from my old job in media systems where provisioning things is always a pain, if something can just be plugged in and it works is always nice but its def. not as big of a deal as the display timing stuff for sure
wispy flame
agreeeed
scarlet brook
a product like this would be something we would have employed there a ton
weird display shapes was always a demand and always a pain to deal with
scarlet brook
that high res stuff would def. be way interesting!
the only good way to use these atm is with the very expensive and clunky HDMI to DSI boards
or figuring out their weird DSI magic sequence
which somehow is never quite documented correctly if at all
https://www.theverge.com/2019/3/6/18253029/kia-imagine-concept-car-21-screen-dashboard-geneva-motor-show-2019
project I did at my old old job, that was a huuuge pain to get going haha
wispy flame
thats a lot of toshiba 357s
scarlet brook
haha yes
wispy flame
ok cool - well ill be around this week, let me know how it goes and we can adapt
scarlet brook
sounds good! I will work on an outline first, share that with you and talk to Pi folks to get their opinion on driver side
wispy flame
@scarlet brook kool
wispy flame
hihi just wanna check on whether pi folks had any feedback
scarlet brook
haven't gotten a response yet, will ping by email instead, I think they are pretty busy atm
scarlet brook
as an alternative route we could do proper DDC on the MCU side too, I will have to verify that but the panel-simpel driver does support it.
It would leave us with less flexibility but if they see any issues with a new driver being added that could be a viable Plan B that still allows not needing to keep upstreaming new panel definitions
scarlet brook
@wispy flame Got a bit side tracked with accounting stuff the past days but also had to brew a bit more on all this.
On the software side, over the weekend I think I want to prototype using an external DDC EEPROM (or emulation in MCU, I'm sure there are some libs for this already) to configure the panel-simple driver. Should be quick to do, I think I have some DDC compliant EEPROMS in stock.
The upside of using an EEPROM for it would be that we can use the Linux tools to generate an EDID binary and writing it back to the EEPROM, save a lot of coding there. The EDID EEPROM could then be RW and be provisioned together with the MCU via our little tbd utility. The whole EDID aspect to it could be fully hidden by the user through that utility if desired without much effort I think.
The MCU could of course also emulate it if we want to save that part but afaik the EDID EEPROMs are also dirt cheap.
With that approach we would be able to skip a custom driver, at least for the imo most important goal of not needing to keep up with panel timing definitions in kernel drivers.
If the EDID stuff works as expected it would also be easy to move to a more modified driver down the line if we do see rough edges that could be avoided. For users and written guides nothing would have to change as the main interface would be the custom device-tree overlay (upstreaming that is no issue at all, I see those getting merged all the time for the most fringe hardware). Swapping out what driver we load with that later on would not make any difference for the user.
I sketched up some diagrams for both the software and hardware side of how I see things atm: https://miro.com/app/board/uXjVMonFQjI=/?share_link_id=149945836868
For the hardware diagram I made two variants, one that would utilize the 40 pin header and one that wouldn't.
I definitely see your point of not wanting to interact with the 40 pin header at all, it makes for a less convenient form factor and does take away a bit from the win of freeing up all the precious GPIO vs just using the RPI DPI peripheral. You can of course make it stacking and what not but its not as nice, esp. if you want to use a different HAT.
My main questions would be, do we want to definitely skip IRQ (at least by default, can of course always have an optional pin header for those types of signals).
And then how do you see power? On the second rev. you removed the USB-C, were you planning on only boosting the 3V3 from the DSI conn?
While probably workable for the smaller screens I think that would hit its limits quite quickly with more high res stuff that has higher demands on backlight and panel driver consumption.
wispy flame
@scarlet brook ok yeah i would proto a quick PoC
i was going to have 5V and GND wires in, for the bigger backlight needs, or power-only USB
dont worry about that part - i can do power budgeting 🙂
ill try to catch you during the weekend
scarlet brook
gotcha 🙂
don't feel the need to be active during the weekend tho! My schedule is all over the place so the differentiation between weekend and weekdays is quite muddy for me.
My plan is to solder one of those eeproms to a breakout, hook it to the pi and give the ddc feature of the driver a spin.
Can chat about results on Monday!
wispy flame
@scarlet brook ok sounds good - try to not think about the 'final' hardware configuration - just need ya to focus on the device driver coding/setup and we will adjust hardware to match
scarlet brook
of course! and sounds good 🙂
Mostly made the diagrams for a better overview for myself of what does/should talk to what
scarlet brook
EDID seems to work! Both in form of the EEPROM and as a file override. The file override didn't seem to work previously, it seems like the dt overlay needs to enable the DDC bus in order for the driver to care about an EDID file
one problem that remains is that you still need to chose some panel, even if the panel info comes via DDC.
So if I choose the pi screen as the compatible string, it will load the mode settings for that panel and the window manager then has the mode for both what came out of the driver definition and what was read from the EDID:
I need to see if its possible to present or force a preferred resolution, it seems the window manager just chooses the highest resolution available
another way could be to define a new dummy panel in that driver with a really low resolution that would never be chosen unless something failed
hm yea the preferred timing bit is already set in the EDID, so thats a window manager quirk that needs to be worked around
used this part for physical testing: https://ww1.microchip.com/downloads/en/DeviceDoc/21682E.pdf
but doesn't really matter what part is used as long as the EEPROM implements DDC, there is probably cheaper alternatives out there
heck maybe a normal eeprom is also okay, this one also just responds to 0x50 like others. In this case we are only using the newer I2C mode anyway
wispy flame
@scarlet brook ehh whats the difference between DDC and not? ive always just used totally generic 24LC for HDMI EDID chips
scarlet brook
I'm hazy on that myself, my understanding is that its mostly older versions of the protocol that behave a bit outside of the I2C specs, in case of this part f.e. it by default continously streams its content if you send a clock to its vclock input.
I have not used that for my test and just used the I2C interface.
If you had already used a standard EEPROM in the past then I would say its probably totally fine and we don't have to dig to deep into that, we only interact with Linux systems anyways, no need to care about the legacy bits.
scarlet brook
ok cool, so its possible to define a panel with no modes/timings at all. As long as the EDID provides a mode it seems fine
that means if the MCU does all the configuration we could get away with only adding a boiler plate "EDID panel" to the panel-simple driver. That should have no issues getting merged into the Pi Kernel.
I would also then merge our tbd device tree overlay(s) so that users only have to modify config.txt and not also copy files and or compile stuff.
scarlet brook
@wispy flame one thing that came to mind, do you want support for controlling backlight? I see you got the PWM pin hooked up on the ATTiny.
scarlet brook
I'm sure an existing backlight driver could be hijacked, otherwise I was thinking that it might be a good idea to stay in the DDC route. One issue we would have by not having a custom driver is not being able to forward certain events like display sleep.
The old DDC/CI interface is pretty simple from what I can see. There is also a newer backwards compatible protocol call E-DDC, from what I can see that mostly just adds a few more things.
But implementing a basic DDC/CI client doesn't sound like all that much work, need to provide a capability "string" to the host and then listen to "VCP" commands that give you info like desired brightness setting, really just a simple I2C interface
scarlet brook
@wispy flame ok so while its technically all supported by the standard, its actual use is so spotty that you don't get default behavior in most Linux distros for backlight and DPMS control over MCCS/DDC, including the Pi OS.
I think the next best thing here would be to implement some portions of the Raspberry Pi 7" Touchscreen drivers, mostly their backlight driver which seems to give us everything we need, a signal for backlight value and a power state.
Alternative would be to submit a new kernel driver as planned or have no OS side power state or backlight control.
one benefit of the RPI driver route is that we would get DSI output during bootloader, which would be the wrong resolution in most cases but its something of an immediate sign of life at least.
I would like to ask them if they would be willing to implement EDID readout for DSI to have the correct resolution also in the bootloader. They already have that in place for HDMI so it would not require substantial work on their end, just probing one more I2C dev
scarlet brook
6by9 who is handling DSI at RPI already indicated that they are generally open to supporting more panels in the firmware/bootloader so maybe they are open to that, just pinged them in a GitHub issue about this.
scarlet brook
@wispy flame ok so bootloader seems to be a no go but possibly open to extending HAT functionality to the DSI I2C which would be really cool. Bootloader support would be really nice but def. not a must have.
Another thing that came up in the discussion is that upstream linux made some really interesting additions to panel-simple that lets you define all the bus settings and display timings in device-tree, which was always a really heated debate and there was a strong no for this in the past.
Seeing this is encouraging as adding the analog of that for DSI would be pretty simple and it sounds like Pi might be open for that.
If the firmware change would happen that HAT EEPROMs also get scanned on the DSI port that would make this a super seamless fully configurable thing for us with minimal driver work really.
https://github.com/torvalds/linux/commit/4a1d0dbc8332231d1d500d7a1d13c45457262a97
scarlet brook
got green light from Pi for the driver changes, will get started on that, this would in the distant future also allow even other platforms than Pi to make use of this without any platform specific work, not high on the priority list probably but a nice thing that kinda comes "for free" this way
wispy flame
@scarlet brook hi sorry last two weeks were totally nutty
im back
ya got your invoice in so that will be 👍
scarlet brook
ah hi 🙂
no worries I figured you are probably down under with stuff
currently busy with the kernel driver changes on my end that I had discussed with the Pi Engineer
Had sent my last invoice for August to Stella last week or so. Was planning to just do monthly cadence there but can also send them more regularly if that works better.
wispy flame
@scarlet brook monthly or biweekly (semiweekly? bimontly? every two weeks) also good!
i have to review your prior messages to see the state
i did get the RGB666 displays all working with ESP32-S3 so its kinda nice to have a working test bed for the settings/config that is quick to update and verify.
scarlet brook
i did get the RGB666 displays all working with ESP32-S3 so its kinda nice to hav...
ah cool! Testing 666 would be interesting to try with the Linux drivers, so far that was all fixed to 888 by piggy backing of the Pi touch panel definition
want me to do a tldr recap of status?
scarlet brook
@wispy flame
okay so talked with Pi engineer, we agreed it would be acceptable to modify the panel-simple driver to allow for panel definitions in device tree including all the special settings for DSI because someone already did the same for DPI there. That modification is what I'm currently doing and am pretty far there.
With that we have the choice of providing everything via device tree or a combination of fixed config for ICN specifics and panel timings via an EDID (panel-simple supports EDID already, nothing to be done there).
We also talked about the possibility of providing a HAT EEPROM for the device-tree via the DSI port. That has some challenges with everything pre Pi5 but would be more straight forward on Pi5. So that might happen down the line, if it does it could become plug and play so to speak but thats future talk.
I also looked into the best pathways for backlight support, wasn't sure if you want that though, just looked on a surface level but no coding.
wispy flame
Sorry, I had to log into my mobile device reading now
OK sounds like let’s keep an eye on the EDID like idea but not try to implement it yet, it would be great to have eventually, but I think there’s just a lot of engineering in the air with the pi five release
But having the panel simple driver be configurable via de device to overlay would be really really really nice because it would suck to have to create a new driver for every display variation
For the back light control don’t worry about it, I might try to mimic some known I2c device
scarlet brook
OK sounds like let’s keep an eye on the EDID like idea but not try to implement ...
agreed, the solution would also work on Pi5 but yea there is work to do to provide a not awful way to create those EDIDs (or pre create them for every panel you sell).
I think main take away is that adding an EEPROM or even just a footprint could be useful for the future, either EDID or HAT EEPROM could make use of it.
wispy flame
I will put a footprint for the EPROM on the boards on the final rev, and we will try to get it working eventually!
scarlet brook
For the back light control don’t worry about it, I might try to mimic some known...
ok cool yea thats also where I landed, there the existing Pi driver for their backlight command set might actually be a good candidate because thats loaded by default
or yea some random TI one that has a driver thats already shipping enabled with the Pi Kernel
wispy flame
OK so I think the best thing for you to work on right now is the implementation for that DTO configurability in the panelsimple driver, and then once that’s working we’ll see if we want to add more. I really do think that for the I CN configuration we will be using and off pi micro controller like an attiny.
scarlet brook
on the same page there 🙂
wispy flame
Although, I suppose, if you are already in that code, and you can add icn configurations chunk, you might as well try it… Especially if you found that the icn does not actually conflict with other devices on the i2c bus
scarlet brook
with in that code you mean the panel-simple driver?
wispy flame
Yeah right, that’s what I think you were intending? That not only could we can figure the panel timing data but also we could blast out that I to see configuration to an optional ICN chip?
like, upstream Linux kernel Folx would absolutely not take this, but maybe razpi would lol
man this speech to text kinda sux but you know what i mean
scarlet brook
in that driver we can't unfortunately add any sort of init code, technically we can of course but the idea of that specific driver is to be used with devices that do not need a complicated init sequence, if they do then they should go into their own driver instead as is currently the convention. In our case if the config happens in the hardware itself on power up we can treat it as a "simple panel" and just turn on DSI with the DSI flags we need like lane count, color mode and all those funky DSI specific things like video burst or whatever.
wispy flame
ok cool thats fine. was worth a shot 😅
scarlet brook
there are several longer buts tho 😄
if you would be interested in enabling a no MCU workflow that also has pathways that are not custom driver
like the work I do right now would also enable the use of the existing ICN6211 panel driver without adding a definition for every panel to the kernel.
Thats sort of what Pi is doing in their newer driver setup for the touch panel but instead of us adding a fixed panel timing definition to panel-simple we could use the DT side configuration for the panel but in theoery the Kernel driver could still init the ICN
but I have to add that I did not have much success with that before when I was trying out the ICN kernel driver so that might be a bit more whacking with the hammer to get playing nicely or potentially some patches (which would surely also be accepted, at least on the RPI side, they are less fussy than upstream)
the panel-simple driver has a good chance of getting upstreamed btw, so we could hopefully have all of this work on other SBCs in the distant future, the Pi DSI pinout has gotten pretty common
wispy flame
ok please focus on that then!
we can ship hardware with that code working - which always helps fund more work 🙂
scarlet brook
meaning the panel-simple + icn kernel driver combo or panel-simple with mcu side config?
wispy flame
@scarlet brook woops sorry missed that message
just getting the panel-simple working with DTO
btw do you know how to compile kernels out of tree for quick iteration
https://github.com/adafruit/Raspberry-Pi-Installer-Scripts has some examples of how its done for our fix to the ST7789 driver
scarlet brook
you mean out of tree kernel modules?
scarlet brook
aah, yea thats what I'm doing atm, I only compile the module itself, is just still annoying 🙂
wispy flame
on a pi 4 it would be pretty fast, altho of course you can crash once in a while (but i usually get a good 6 iterations. you can also printk which is handy)
ok yah its a lot of rmmod && make && insmod
ok
just checking!
scarlet brook
thanks for checking!
there is a lot of scripts running in the whole build system which seem to take the majority of the time vs. compilation. I'm sure that can be optimized but not really something I feel like digging into, so was hoping there are some existing guides for optimizing the build systems for more targeted use cases
oh and the driver can't be hot reloaded, causes a kernel oops and then its borked. The reboot for re-execution def. also eats time
scarlet brook
good news, driver is working. Fully device tree defined timings and dsi settings 🙂
Some more testing to do but feels done for the most part
wispy flame
@scarlet brook 😻
great timing
@scarlet brook is it ok if we sneak peek this on socialz?
scarlet brook
sure!
scarlet brook
@wispy flame the driver is probably going to be more spread out next week with doing the PR and getting feedback etc.
Any other stuff you would like me to work on next week?
Either for this or if there is other projects that you would like to see work on, I don't mind switching between things.
I also had some ideas for products for Pi5 that I do not wanna do for DD due to support reasons but might be interesting for Adafruit if you are interested.
wispy flame
@scarlet brook hiya i think just getting the DTO PR integrated is most important. if you're feeling up to it, crafting a couple DTO examples would be good too. for the backlight control, is there some 'already in the kernel' driver that uses I2C we can piggyback onto?
scarlet brook
@wispy flame yea there are a fair few. There is also the option to implement a PWM/GPIO expander which could then be used for some IO and PWM control and a PWM device can be hooked into the generic pwm backlight driver.
F.e. https://github.com/raspberrypi/linux/blob/rpi-6.1.y/drivers/pwm/pwm-pca9685.c
maybe a question of what is more work, own linux driver or writing code to emulate an existing device
all backlight drivers currently in the pi kernel can be found here
https://github.com/raspberrypi/linux/tree/rpi-6.1.y/drivers/video/backlight
many or most of the I2C ones are implemented as multi function devices whose main definition is found here
https://github.com/raspberrypi/linux/tree/rpi-6.1.y/drivers/mfd
scarlet brook
@wispy flame going into the week thinking I won't have enough to do and then having way too much other stuff going on 🙂
But I now submitted a draft PR to the Pi Kernel for feedback. This should then hopefully make it into the next Pi OS release.
I made sure it abides by all the various Kernel code and patch guidelines to not cause any unnecessary friction.
that init code for the 6bit display would be cool to have, then I could try if things work properly with that. Assuming that is one of the displays you had sent me.
scarlet brook
it looks like on Pi5 the combination DSI/CSI port gets two IO pins like it did for the 4 lane CSI port on CMIO. See the CD_IO pins
for a future Pi5 version of the board it could make use of an interrupt pin for the touch
wispy flame
hiya sorry the last weeks have been very chaotic 🙂 lets catch up this week. i would like to wrap this up
scarlet brook
sounds good!
wispy flame
@scarlet brook we can do more just want to verify that PR and get a hardware design out 🙂 fyi i got a Pi 5 sample too
scarlet brook
cool!
yea had a bit of discussion with Pi on the PR, some changes to do but nothing major.
and nothing that would block finalizing hardware design
wispy flame
@scarlet brook what are they waiting for to merge?
scarlet brook
refactoring one part, right now there is a bit of duplicate functionality. My approach was to only add and not change to not cause too much discussion upstream.
Pi engineer would like to have it addressed a bit more general purpose, which I totally agree with, was just a bit too timid to make more substantial changes there. I trust them if they see that as okay to do, they deal with upstream regularly unlike me.
I think I should be able to have an updated patch on Monday. Last week was very blocked out by accounting work on my end.
scarlet brook
wispy flame
thankya
btw i dont care a ton about configuring the ICN via kernel/dto or mcu
we need a mcu ayways so it was just for convenience, and because the ICN responds all addrs (which it appears to just do for zero-length-writes not actual queries ?)
scarlet brook
it seems to be yea! Otherwise I would have expected things to malfunction with other devices on the bus
and yea I see that, I think the only bigger reason for MCU side init would be that there is no need to get much else enabled in the Kernel and that you could show a "stable" display before the Kernel kicks in, which might be of interest to some applications
wispy flame
ok ill read the PR in more detail so i can see what they're comign from .looks like its still pretty fresh so we can probably adjust to get it merged 🙂
scarlet brook
ah and backlight we haven't fully addressed yet, would need to decide on a driver there
scarlet brook
ok ill read the PR in more detail so i can see what they're comign from .looks l...
I think no critique of anything in principal, really just some details of the where (and two bugs), felt no opposion to get it merged once adressed
(and had an explicit "pls do" from 6by9 before starting)
wispy flame
Are you testing on a pi four or pi five
scarlet brook
Pi4, I did a quick test on Pi5 last week but did not get that working but also had trouble with the official display, that seems to be still a bit unfinished SW wise
wispy flame
OK cool, do you mind giving me the list of command you used to compile the out of tree colonel module
I'm using speech to text, but you know what I mean 🙂
scarlet brook
sure! Can also send you an image if you want to get started more quickly.
tldr; follow the Pi4 64bit flow in this guide https://www.raspberrypi.com/documentation/computers/linux_kernel.html#building-the-kernel but clone my fork which has the patch applied
https://github.com/timonsku/linux/tree/rpi-6.1.y
wispy flame
sure if you want to upload an eight gig image, I can try that too, but it's also good for me too. Try compiling.
You'll need to find some sort of file sharing for the image, good luck!
scarlet brook
example dts for the 840x480 panel
scarlet brook
I made good experience with these cards btw, esp. on Pi5 with the higher speed SDIO. Writing fresh image only takes about a good minute with an UHS-I/II capable reader.
https://www.amazon.com/dp/B09X7BK27V
wispy flame
oh yah i have that set up with a usb3 port its pretty good!
scarlet brook
https://www.dropbox.com/t/GY8MsQbwsrqAuufl
dev image from the Pi4, kernel dir in /pi/home
should have default pw
have a build.sh in the kernel dir to do full kernel build and install
filesystem is enlarged to 32GB
scarlet brook
ok so something changed in the latest Kernel changes for Pi5 that breaks things and not entirely sure what it is.
I thought it was just Pi5 stuff but things don't seem to be working anymore on Pi4 either with the latest Kernel.
Thats a gotcha for the image I uploaded, at boot it still has the old kernel with the patched module but if you compile the cloned kernel directory that uses the latest changes and things seem to stop working there, even using the official 7inch overlay using the bridge driver which always worked previously so this might be a regression on Pi side.
scarlet brook
ok getting somewhere, at least back to being able to get it working with the hacked 7inch overlay
@wispy flame btw would you work on firmware for the MCU or do you want me to work on that?
I could use some parallel tasks, the current driver stuff is def. quite "waiting" heavy
ah and one other point I remembered that would speak heavily for MCU side config, we need it for those displays that need a SPI or I2C init before they accept a DPI stream, like that square one you were working one.
scarlet brook
fixed it yesterday, was a mix of some behavior change coupled with the image now having an initramfs that needs to be deleted for a new kernel and modules to actually be loaded
which also means its now working too on PI5 🙂
scarlet brook
got some Pi5 DSI cables finally. Multi display also working now with the latest changes 🙂
scarlet brook
@wispy flame thinking about the backlight driver bit. I'm wondering if it might be worth adding a seesaw driver to the kernel.
By defining a multi function device that does at very least GPIO and PWM it would be pretty multi purpose to hook that into lots of other subsystems without needing a subsystem specific driver. A GPIO controller can be used in pretty much any other driver that requires a GPIO to toggle something and PWM can be used for backlight.
Adding a driver like this should face no objection there is loads of oddball little drivers like that in the Kernel is pretty much what Pi did for their own display.
It's much more straight forward than the DSI stuff was so far as it doesn't require understanding decades of Kernel lore to make small changes. Could start small with GPIO and PWM and add other interesting seesaw functions down the line.
scarlet brook
like thinking beyond this specific product, there is I think loads of potential to have more "plug and play" Pi friendly products that integrate more into native systems beyond Python without needing to have a driver in place for every single one but wiring them into subsystems via device tree and the seesaw driver acting as the glue
scarlet brook
this what I would see for this board:
use a seesaw based firmware, if I understood you correctly previously there was already an interface that would allow sending sequence data to an (emulated) EEPROM that can be executed on boot to the attached device?
That would be the only bit that would be needed outside of the basic seesaw functions.
For the sake of getting things out the door that could be for now be a python application on the Pi side to send the icn config and optional init sequence for the panel and interactive backlight control.
That would be I think the least amount of new code to get to a feature complete state. If its CPY it would also make it possible "for free" to mass provision via a little CPY devboard which would be a nice feature if you deal with lots of panels or factory testing.
Then once a potential seesaw driver gets pulled into Pi Kernel it could be used with that instead for using OS interfaces for brightness and power control.
Having a generic glue kernel driver like this seems very attractive to me as you could likely support pretty much any future need with device tree side configuration.
Not just Kernel interaction but also things like HID e.g. "on pins 2&3 an encoder is attached, map this data as a scroll wheel on a pointer device", for which you typically otherwise would need a separate USB connection and USB capable MCU.
scarlet brook
no hurry, am here all day
hardy merlin
@scarlet brook ok back, turns out it was part_name_pattern2 = r"^\s*(?P<Part_Number>\d{2,})\s+(?P<Part_Name>.*?)(?=\s+NONE)[^\n]*\n\s*[\d\~\-\s]+[o0]{3,}[^\s]+(\s+(?P<Cost>\d+\.\d+))?[^\n]*(?P<Qty>\d+)"
duh
scarlet brook
lol thats a cursed regexp
hardy merlin
OCR'd PDF of a 100 page purchase order that is a rotated collection of scanned in JPGs of a paper based invoice system
it was cursed from birth
let me commit, one moment
scarlet brook
haha
hardy merlin
i need a drink
ok passed off to the person running it whew
ok let me review backlog
one good news is i did get a whole bunch of random wierdo screens in stock
scarlet brook
I saw those trickle in 🙂
hardy merlin
ok let me look at the github PR thread too, i thought i sub'd to it but i never got any notifs
ok lokos like...they're sorta at a pause point
like not actively working on the merge, because they have some trepidation (?) or am i misreading
scarlet brook
currently waiting on feedback for the latest patch, that implemented mostly all the things they noted in the first round
just marked it as ready for review, not sure if they maybe have notif filters if its in draft mode
but they are also quite busy still with Pi5 kernel work so might be just a lack of time atm
hardy merlin
yeah is that this PR https://github.com/raspberrypi/linux/pull/5640 or a different one
scarlet brook
yea thats the one
scarlet brook
no the firmware is closed source but there was a discussion in the issues there that kicked off this change
hardy merlin
ok just downloading this all back into my brain
actually - if we could do a vid chat i think it would be faster for you to tell me the status and what we can do next
since there's a lot of context 😄
scarlet brook
right yea, it went from that main topic to how DSI panels can be better supported. I was asking if they were open for reading EDID in the firmware for bootloader support of non Pi panels but 6by9 did not like that but suggested that panel definitions in device tree would be fine and that any potential support in the future would only come via kernel additions like that.
I was not aware that device tree side panel definitions were already merged into the mainline Kernel as that was a huge no no for years and that aligned pretty well with what we want, the only thing missing was that this was hardcoded to only be available for DPI parts but not DSI panels or parts that pretend to be a simple DSI panel
scarlet brook
since there's a lot of context 😄
haha yes! The biggest task for this was definitely thinking, not coding.
lots of stake holders to keep in mind
hardy merlin
kk
...thinking...
ok let me know if/when you could do a voice/video for ~20 minutes
and i think we can chart a path
hardy merlin
ok i dont think you can do video via discord...
scarlet brook
its possible, but I think you need to do it via DM
uncut yew
@scarlet brook @wispy flame I'm really really sorry for the tags, especially after so many years of working on this project. I'm working on a custom cinema camera built on the Raspberry Pi 5 and the 4inch square display is the best fit for my project. There are DPI versions on the market but I really hate them because the connection is too bulky for what I have in mind and they also use up all the GPIO pins. I found this project of yours and its all I ever wished for, the 4 Inch Square display with a DSI board is my dream. One issue is I can't get the image right no matter what I try sadly
I got to this point with it
It should show this for reference
