Re: Black box flight recorder for Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jean Delvare wrote:

Hi Folks -

Impressed with Krzysztof doing the work!

The first part is the "console" driver (obvious parts removed). It works
with both my Asus A7V333 (VIA KT333, VIA SMBUS driver) and with VGA DDC
interface on a Cirrus Logic GD 5446 VGA chip (simplified source attached
as well). Using respectively 2464 and 24512 set to ID 0x57.

How do you intend to connect your device to the DDC channel if there's
already a monitor connected to the VGA or DVI port?

For both VGA and DVI I think the optimal answer is to build a small back-back breakout adapter. The parts seem to be quite reasonably priced and reasonably available, eg from Farnell (www.farnell.co.uk):

VGA: Plug partcode 1071807 GBP 1.76   Socket partcode 1071811 GBP 2.10

DVI: Plug partcode 9965190 GBP 1.38   Socket partcode 1012227 GBP 2.01


If the original cabling looks like this:

  <Video card Socket>
    |
  <Original Cable Plug>
    |
    |
    |
  <Original Cable Plug>
    |
  <Monitor Socket>


then the breakout concept looks like this:

  <Video card Socket>
    |
  <Adapter Plug>
    |--------------------- I2C signal wires broken out
    |                      All wires passed to corresponding pins
  <Adapter Socket>
    |
  <Original Cable Plug>
    |
    |
    |
  <Original Cable Plug>
    |
  <Monitor Socket>

Beware that many monitors have EDID EEPROMs responding to all I2C
addresses within the 0x50 - 0x57 range, so it'll be hard to add an
EEPROM on the bus for your own purpose without hitting an address
conflict.

The adapter does give an opportunity to interrupt the connectivity of the I2C to the monitor if worst comes to worst, I guess no traffic is typically present after X init or Linux touching it. Pretty ugly that things ignore b2-b0 of the I2C address.

A whole other way forward is to consider to replace the EEPROM from the original proposal (which does provide its own advantages such as simplicity, I accept) with something else that ends up on another PC. In this concept some logic presents a fake I2C peripheral to the DDC interface at an I2C address of our choosing. This logic acts as a bidirectional "UART" type of thing, allowing transfer of data in both directions between the Linux box being debugged and another PC.

I designed something conceptually similar for the effort to hack the original Xbox, which was very effective (and is GPL'd):

http://warmcat.com/milksop/filtror.html

However this would be much simpler, not even needing RAM. It can hook to the second PC by the same I2C method, parallel printer port, RS232 or USB depending on the level of complexity of the design.

I guess the link will feel quite like a 9600 or 19200 baud serial port in terms of throughput.

The following is an adapter for Cirrus Logic 5446 VGA on my old R440LX
test machine:

There is a locking problem - the VGA is (can be) shared between VT console,
X11 and the driver. I'll look at CL FB driver to see how/if it's done.

The current trend is to merge the DDC access driver into the
framebuffer driver. This solves one of the conflicts, and also makes
sense because the EDID data can be used to automatically setup the
framebuffer. We still have a few standalone DDC access drivers
(i2c-i810, i2c-savage4...) but they are considered deprecated and will
probably be deleted in a near feature.

This will be a second problem for you though. Most distributions don't
make use of hardware-specific framebuffer drivers by default, but use
the VESA framebuffer driver. This driver doesn't have DDC support.

Maybe this effort is considered too esoteric, but it seems to me to be a reason to keep the DDC access drivers standalone, the hardware-specific framebuffer drivers can call through to them and we can use them in a clean way. I realize this is a bit of a late objection and that there was not previously much point to keeping them as separate things in the world.

Note that I am not trying to dicourage you, Andy's idea has merit for
sure. I just mean that it won't be usable by everyone out of the box.
People will have to use the right driver and pay attention to address
conflicts.

Address conflicts we can solve by widening the scope and powers of the interface into a generic communications link by adding a little hardware, removing the address clash. If basically magic-ing a cheap-to-drive comms link out of nowhere, on most all PC-type hardware, has value then maybe it can sway people to keep the separated DDC drivers.

-Andy

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux