> It's 5.25" bay VDF+IR called Antec Multimedia Station or Antec
> By the looks and features it's almost identical with the retail iMON
> VFD but it has different device id.
> Bus 004 Device 002: ID 15c2:0044 SoundGraph Inc.
> I've tried to add the device id to the Lirc source but no succes so
> far. I'm no pro in this matter.
> Is there any info i can give to you so that you could add this
> device to the future releases?
Do you know if it is a VFD for sure, or if it is an LCD?
The LCD model for mine - 15c2:0038 looks like this:
(see the little icons and such
around the display)
There are some somewhat outdated but still valid instructions for the
15c2:0038 device here that may be of assistance to you:
Another way to see if it is the LCD is to look at the endpoints
defined on the device:
run "lsusb -d 15c2:0044 -v | grep bEndpoint"
and if the output that has 2 lines that are labeled "IN" like this:
lsusb -d 15c2:0038 -v | grep bEndpoint
bEndpointAddress 0x81 EP 1 IN
bEndpointAddress 0x82 EP 2 IN
Then it is most likely that you have an
STEP 1: Make sure that the HID driver isn't claiming the device.
First, make sure that the USB HID driver isn't taking control of the
device. The easiest way to do this is to use usbfs:
mount -t usbfs none /proc/bus/usb
look for the device.
If it says driver: usbhid - you need to first get the usbhid driver to
ignore the device (see that blog post for instructions on this)
STEP 2: Test that you can drive the device with arbitrary input
There is a some sample C code someone wrote to help test the reverse-
engineering of the protocol called 'imon_poke' - that you can compile
and run to try to see if you can draw abritray things on the screen.
When I was troubleshooting the 15c2:0038 device, I documented pretty
thoroughly some of the steps I was taking to get to the bottom of it:
In there, you will find the imon_poke code. You will want to change
the code at the top that says the device ID from 0038 to 0044 - and
then compile and run it. (The gcc arguments to compile it are in a
comment at the top of
Once you run imon_poke - if you see it draw a line on your screen -
you should be able to confirm that the device exists and it has the
same driving protocol as the recent LCD screens.
STEP 3: Get the LIRC driver to work with the device
Use the CVS head code - as it has the latest changes for the lirc_imon
At this point, you will need to add the device to the lirc_imon.c list
of devices and
recompile your lirc_imon.c and replace any lirc_imon.ko
with the newly built one. To help you identify if the newly built one
is working - you could throw a custom version number in your local
build so you will be able to very easily tell when you check the
output in dmesg that your version is loading and not some older version.
Once you have the lirc_imon.ko in place you can kill any lirc
processes, modprobe -r lirc_imon, and then modprobe lirc_imon debug=1
debug=1 is optional, but it will give you some more debug output)
- and then see if /dev/lcd0 or /dev/lcd1 gets created...
STEP 4: get your LCD to actually display something useful (outside the
scope of LIRC)
If they do, then your next step will be to get LCDd and lcdproc to
work with them - but that's no longer a lirc issue. That first blog
that I pointed you to has another page where he describes how to get
lcdproc to work with the imon LCD.
If your device does, in fact, turn out to be a VFD - I personally
haven't done much with the VFD's - but I think you should just be able
to skip to step 3 and add it to the VFD list and then see if you can
write ASCII out to the LCD device - as I think it just echoes ascii
text (the LCD models draw bitmaps, but I think the VFDs let you pass
in plain text)