[HN Gopher] DDC OLED: how to drive a tiny display from an HDMI p...
___________________________________________________________________
DDC OLED: how to drive a tiny display from an HDMI port. (2022)
Author : fanf2
Score : 124 points
Date : 2024-04-25 16:42 UTC (6 hours ago)
(HTM) web link (mitxela.com)
(TXT) w3m dump (mitxela.com)
| Liftyee wrote:
| Fun little project, wonder if DDC could be used as a way to
| control devices like HDMI capture cards or KVM switches? Honestly
| surprised that bare i2c interface is exposed to the OS and not
| hidden by some firmware...
| IshKebab wrote:
| Yeah, the main issue with I2C for this sort of thing is device
| discovery. It doesn't have any mechanism for it so you would
| need to magically know your device's address.
|
| I believe for things like controlling monitors they just hard-
| code the addresses. I think that's how it works anyway.
| Unfortunately the DDC/CI spec is _really_ badly written,
| incomplete, _and_ full of legacy stuff that nobody actually
| implements.
| toast0 wrote:
| > Yeah, the main issue with I2C for this sort of thing is
| device discovery. It doesn't have any mechanism for it so you
| would need to magically know your device's address.
|
| The typical address space is 7-bits, so you can just try a
| transaction to everyone... Or have some convention about what
| device number the display is?
| dmitrygr wrote:
| Problem is: _every_ i2c transaction is a READ or a WRITE.
| The spec is mum on the semantics of what that means. Some
| devices will get into a weird state or irrevocably pop data
| off a FIFO if you READ them (eg: some IMUs). Others take a
| WRITE, even with no data, to have a non-idempotent meaning
| (eg: SMBUS). Some devices will not even ACK their address
| on a READ request unless it is preceded by a write and a
| RESTART. Basically there is no safe way to scan an i2c bus
| and be sure you did not modify some state or put some
| device into some weird state.
| buescher wrote:
| Right. But if you have a finite space of possible i2c
| devices it's not quite that bad. You can scan for known
| addresses and there are frequently mitigations for
| clogging FIFOs - like clocking out the bus or forcing a
| reset - that you might have to do anyway, depending on
| what your failure modes for power sequencing are. i2c is
| just fine when it works, but there are reasons why it can
| be worth spending the extra pins for SPI.
| utensil4778 wrote:
| I2C has no concept of a discovery or identification packet.
| The host can write any data to any address, and you have to
| already know in advance what address and data structure you
| need. The device _can 't_ tell you what its data format is.
|
| An I2C transaction begins with a client address, and the
| host waits for an acknowledge signal that a client has
| answered the message. That's it, that's the only standard
| part. From there, the host _typically_ sends a register
| address and then some number of data bytes, or the client
| sends back some number of bytes. What those addresses and
| bytes mean are totally application-specific. There is no
| standard at all here.
|
| You could absolutely broadcast standard DDC commands to all
| addresses, but you have no way of knowing what actually
| happened. You might have turned off one monitor and set
| another to VGA mode. You might have just crashed some
| random device on the bus. You have no way to tell.
|
| All your host can possibly know is that there is _a_ device
| at a given address, and it either did or did not send an
| acknowledge bit after a command. That 's all the
| information available to you, and it is not enough to do
| what you suggest
| myself248 wrote:
| In recognition of this chaos, https://i2cdevices.org/ is
| putting together a pretty good list.
| FredFS456 wrote:
| That's not technically true - you can probe for I2C
| devices by only sending a START, an address, waiting for
| the client device to ACK (or not), and then sending a
| STOP. I don't think the linux kernel driver allows us to
| do this, but I've implemented this on some
| microcontrollers with lower-level control over the I2C
| hardware. It worked on all clients I tried it on.
| joezydeco wrote:
| You can install i2c-tools and run i2cdetect from
| userspace.
|
| https://learn.adafruit.com/scanning-i2c-addresses/raspber
| ry-...
| 1oooqooq wrote:
| it's hidden on most windows drivers.
|
| on Linux it's exposed and have user tools for most standard
| things. it's infuriating how changing the settings on random
| external displays is easier than most integrated laptop
| screens.
|
| some kvm do abuse that comms channel already. forgot which
| brand but it completely hijacks it and my brightness hacks
| wouldn't work
| myself248 wrote:
| I don't know about that, but I've used it to reprogram the i2c
| EEPROM in SFP transceivers. Cooking up a little board to make
| that easy, actually; I'll publish the files as soon as I prove
| the prototype works.
| amelius wrote:
| Here's a video about making an OLED device from scratch, and all
| the physics involved:
|
| https://www.youtube.com/watch?v=qg8pMUd-tSk
| kurthr wrote:
| Thanks for this more foundational information. It's a bit
| simplified since most displays are flexible now and multi-
| color, but at least it doesn't ignore the entire OLED material,
| TFTs, and display driver IC as if the digital communication to
| the controller was the most important or even remotely common
| solution.
| sgroppino wrote:
| Nice one :D reminds me of my little project back in 2020 with a
| raspberry pi and a similar type of display...
| https://news.ycombinator.com/item?id=25566132
| dang wrote:
| Discussed at the time:
|
| _The smallest and worst HDMI display_ -
| https://news.ycombinator.com/item?id=30869140 - March 2022 (162
| comments)
___________________________________________________________________
(page generated 2024-04-25 23:00 UTC)