incubator-nuttx/drivers/video
yangyalei fd776e8cee fix wait after vfork return error
vfork use waitpid hang father process,
but waitpid release child processs information by default.
So when user call wait, it return errno 10.

Signed-off-by: yangyalei <yangyalei@xiaomi.com>
2023-09-08 00:53:56 +03:00
..
mipidsi inode/i_private: remove all unnecessary cast for i_private 2023-08-29 08:58:07 +02:00
vnc mm/alloc: remove all unnecessary cast for alloc 2023-08-30 14:34:20 +08:00
CMakeLists.txt cmake:fix drivers build block during cmake reforming 2023-08-16 22:38:52 +08:00
Kconfig drivers/video: add Goldfish-FB driver 2023-08-13 11:51:30 -03:00
Make.defs drivers/video: add Goldfish-FB driver 2023-08-13 11:51:30 -03:00
README.max7456 Remove the double blank line from source files 2022-02-20 20:10:14 +01:00
fb.c mm/alloc: remove all unnecessary cast for alloc 2023-08-30 14:34:20 +08:00
goldfish_camera.c fix wait after vfork return error 2023-09-08 00:53:56 +03:00
goldfish_fb.c drivers/video: add Goldfish-FB driver 2023-08-13 11:51:30 -03:00
isx012.c drivers/video: Fix returned errno in error cases 2023-07-31 03:28:54 -07:00
isx012_range.h drivers/video: Support spot position setting 2023-04-27 17:05:32 +08:00
isx012_reg.h drivers/video: Support spot position setting 2023-04-27 17:05:32 +08:00
isx019.c drivers/video: Fix an issue isx019 may freeze 2023-08-29 13:37:01 +08:00
isx019_range.h drivers/video: Support spot position setting 2023-04-27 17:05:32 +08:00
isx019_reg.h drivers/video: Support spot position setting 2023-04-27 17:05:32 +08:00
max7456.c mm/alloc: remove all unnecessary cast for alloc 2023-08-30 14:34:20 +08:00
ov2640.c drivers: video: altair: nxstyle fixes 2021-01-26 05:11:58 -08:00
video.c mm/alloc: remove all unnecessary cast for alloc 2023-08-30 14:34:20 +08:00
video_framebuff.c Revert "drivers/video: Don't need update vbuf_tail in dequeue_vbuf_unsafe" 2023-07-26 07:45:30 -07:00
video_framebuff.h drivers/video/video: add poll support to capture 2023-02-13 23:17:45 +08:00

README.max7456

drivers/video/README.max7456

23 March 2019
Bill Gatliff <bgat@billgatliff.com>

The code in max7456.[ch] is a preliminary device driver for the MAX7456 analog
on-screen-display generator. This SPI slave chip is a popular feature in many
embedded devices due its low cost and power requirements. In particular, you
see it a lot on drone flight-management units.

I use the term "preliminary" because at present, only the most rudimentary
capabilities of the chip are supported:

 * chip reset and startup
 * read and write low-level chip control registers (DEBUG mode only)
 * write CA (Character Address) data to the chip's framebuffer memory

Some key missing features are, in no particular order:

 * VSYNC and HSYNC synchronization (prevents flicker)
 * ability to update NVM (define custom character sets)

If you have a factory-fresh chip, then the datasheet shows you what the factory
character data set looks like. If you've used the chip in other scenarios,
i.e. with Betaflight or similar, then your chip will almost certainly have had
the factory character data replaced with something application-specific.

Either way, you'll probably want to update your character set before long. I
should probably get that working, unless you want to take a look at it
yoruself...

The max7456_register() function starts things rolling. The omnibusf4 target
device provides an example (there may be others by the time you read this).

In normal use, the driver creates a set of interfaces under /dev, i.e.:

/dev/osd0/fb
/dev/osd0/raw   (*)
/dev/osd0/vsync (*)

* - not yet implemented

By writing character data to the "fb" interface, you'll see data appear on the
display. NOTE that the data you write is NOT, for example, ASCII text: it is
the addresses of the characters in the chip's onboard character map.

For example, if entry 42 in your onboard character map is a bitmap that looks
like "H", then when you write the ASCII "*" (decimal 42, hex 2a), you'll see
that "H" appear on your screen.

If you build the code with the DEBUG macro defined, you will see a bunch more interfaces:

/dev/osd0/VM0
/dev/osd0/VM1
/dev/osd/DMM
...
...

These are interfaces to the low-level chip registers, which can be read and/or
written to help you figure out what's going on inside the chip. They're
probably more useful for me than you, but there they are in case I'm wrong
about that.

b.g.