FT232BM usb2serial not working

[Ari Kohtamäki]

Already sent this to ftdi-usb-sio-devel, but that list seems
quite quiet. So, I make an other try here...

I have a CableStar 2 PCI DVB-C card with remote module.
When I attach the remote module (IR-receiver) to my
serial port it works OK with VDR using lirc.

I bought an usb2serial converter (FT232BM based) and
can't get my remote working with lirc at all. :(
Converter is recognized as:
Bus 002 Device 004: ID 0403:6001 Future Technology Devices
International, Ltd 8-bit FIFO

I think it fails with ioctl call below:

ftdi_sio.c: ftdi_ioctl cmd 0x80046900
ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x80046900 - check
/usr/include/asm/ioctls.h

I tried to gather as much info as I could below.
Maybe someone can help me to get the converter working.
I really need more than only one serial port...

--
# uname -a
Linux dell.localdomain 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 15:12:59 EST 2007
i686 i686 i386 GNU/Linux
--

# /usr/sbin/lircd -n -H default -d /dev/ttyUSB0 --nodaemon /etc/lircd.conf
lircd-0.8.1[7481]: lircd(userspace) ready
lircd-0.8.1[7481]: accepted new client on /dev/lircd
lircd-0.8.1[7481]: could not get hardware features
lircd-0.8.1[7481]: this device driver does not support the new LIRC interface
lircd-0.8.1[7481]: major number of /dev/ttyUSB0 is 188
lircd-0.8.1[7481]: LIRC major number is 61
lircd-0.8.1[7481]: check if /dev/ttyUSB0 is a LIRC device
lircd-0.8.1[7481]: caught signal
Terminated

--

FC6 2.6.22.14-72.fc6 w/ native ftdi_sio (from FC6) driver:
Kernel messages w/ above driver:

Jan 16 22:04:02 dell kernel: drivers/usb/serial/usb-serial.c: USB
Serial support registered for FTDI USB Serial Device
Jan 16 22:04:02 dell kernel: ftdi_sio 2-2:1.0: FTDI USB Serial Device
converter detected
Jan 16 22:04:02 dell kernel: drivers/usb/serial/ftdi_sio.c: Detected FT232BM
Jan 16 22:04:02 dell kernel: usb 2-2: FTDI USB Serial Device converter
now attached to ttyUSB0
Jan 16 22:04:02 dell kernel: usbcore: registered new interface driver ftdi_sio
Jan 16 22:04:02 dell kernel: drivers/usb/serial/ftdi_sio.c: v1.4.3:USB
FTDI Serial Converters Driver
Jan 16 22:04:02 dell kernel: lirc_dev: IR Remote Control driver
registered, major 61
Jan 16 22:04:02 dell kernel: lirc_serial: no version for "lirc_unregister_plugin
" found: kernel tainted.
Jan 16 22:04:02 dell kernel: lirc_serial: auto-detected active low receiver
Jan 16 22:04:02 dell kernel: lirc_dev: lirc_register_plugin: sample_rate: 0


FC6 2.6.22.14-72.fc6 w/ native ftdi_sio (from FC6) driver:
Driver debug messages when I try to connect to lirc w/ irw:

ftdi_sio.c: ftdi_open
ftdi_sio.c: ftdi_set_termios
ftdi_sio.c: Setting CS8
ftdi_sio.c: get_ftdi_divisor - tty_get_baud_rate reports speed 9600
ftdi_sio.c: get_ftdi_divisor - Baud rate set to 9600 (divisor 0x4138)
on chip FT232BM
ftdi_sio.c: update_mctrl - DTR HIGH, RTS HIGH
ftdi_sio.c: ftdi_set_termios Turning off hardware flow control
ftdi_sio.c: update_mctrl - DTR HIGH, RTS HIGH
ftdi_sio.c: ftdi_ioctl cmd 0x80046900
ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x80046900 - check
/usr/include/asm/ioctls.h
ftdi_sio.c: ftdi_close
ftdi_sio.c: ftdi_read_bulk_callback - port 0
ftdi_sio.c: update_mctrl - DTR LOW, RTS LOW

--

I tried also with newer driver.
FC6 2.6.22.14-72.fc6 w/ ftdi_sio driver from linux kernel 2.16.23.14:
Driver debug messages when I try to connect to lirc w/ irw:

ftdi_sio.c: ftdi_open
ftdi_sio.c: ftdi_set_termios
ftdi_sio.c: Setting CS8
ftdi_sio.c: get_ftdi_divisor - tty_get_baud_rate reports speed 9600
ftdi_sio.c: get_ftdi_divisor - Baud rate set to 9600 (divisor 0x4138)
on chip FT232BM
ftdi_sio.c: update_mctrl - DTR HIGH, RTS HIGH
ftdi_sio.c: ftdi_set_termios Turning off hardware flow control
ftdi_sio.c: update_mctrl - DTR HIGH, RTS HIGH
ftdi_sio.c: ftdi_ioctl cmd 0x80046900
ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x80046900 - check
/usr/include/asm/ioctls.h
ftdi_sio.c: ftdi_read_bulk_callback - port 0
ftdi_sio.c: ftdi_process_read - port 0
ftdi_sio.c: Status only: 261o 140o
ftdi_sio.c: ftdi_read_bulk_callback - port 0
ftdi_sio.c: ftdi_process_read - port 0
ftdi_sio.c: Status only: 261o 140o
ftdi_sio.c: ftdi_read_bulk_callback - port 0
ftdi_sio.c: ftdi_process_read - port 0
ftdi_sio.c: Status only: 261o 140o
ftdi_sio.c: ftdi_read_bulk_callback - port 0
ftdi_sio.c: ftdi_process_read - port 0
ftdi_sio.c: Status only: 261o 140o
ftdi_sio.c: ftdi_close
ftdi_sio.c: update_mctrl - DTR LOW, RTS LOW
ftdi_sio.c: ftdi_read_bulk_callback - port 0

----

# lsusb -v

Bus 002 Device 004: ID 0403:6001 Future Technology Devices
International, Ltd 8-bit FIFO
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 8-bit FIFO
bcdDevice 4.00
iManufacturer 1 FTDI
iProduct 2 USB <-> Serial
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
MaxPower 90mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 USB <-> Serial
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0

---

# lsmod
Module Size Used by
lirc_serial 17940 0
lirc_dev 18804 1 lirc_serial
ftdi_sio 37384 0
nfsd 208817 17
exportfs 9537 1 nfsd
autofs4 24773 2
eeprom 11345 0
hidp 26689 2
nfs 229037 1
lockd 64457 3 nfsd,nfs
nfs_acl 7617 2 nfsd,nfs
rfcomm 44377 0
l2cap 30401 10 hidp,rfcomm
bluetooth 57893 5 hidp,rfcomm,l2cap
sunrpc 161981 13 nfsd,nfs,lockd,nfs_acl
ipv6 278085 28
dm_multipath 21961 0
video 20937 0
sbs 22729 0
button 12113 0
dock 13921 0
battery 14149 0
ac 9285 0
lp 16105 0
stv0297 11329 2
bcm3510 13381 0
lgdt330x 12229 0
snd_intel8x0 36061 0
nxt200x 17093 0
snd_ac97_codec 96613 1 snd_intel8x0
ac97_bus 6465 1 snd_ac97_codec
snd_seq_dummy 7877 0
mt352 10181 0
snd_seq_oss 33473 0
snd_seq_midi_event 11073 1 snd_seq_oss
snd_seq 50609 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
dvb_ttpci 97801 6
snd_seq_device 11981 3 snd_seq_dummy,snd_seq_oss,snd_seq
stv0299 13897 0
saa7146_vv 49345 1 dvb_ttpci
snd_pcm_oss 43457 0
snd_mixer_oss 19521 1 snd_pcm_oss
video_buf 27717 1 saa7146_vv
saa7146 22857 2 dvb_ttpci,saa7146_vv
snd_pcm 74949 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
b2c2_flexcop_pci 12377 14
b2c2_flexcop 29773 1 b2c2_flexcop_pci
videodev 30785 1 saa7146_vv
v4l2_common 20801 2 saa7146_vv,videodev
iTCO_wdt 14693 0
snd_timer 24901 2 snd_seq,snd_pcm
v4l1_compat 17349 2 saa7146_vv,videodev
dvb_core 78953 4 lgdt330x,dvb_ttpci,stv0299,b2c2_flexcop
iTCO_vendor_support 7877 1 iTCO_wdt
snd 53317 9
snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
i2c_i801 12369 0
ttpci_eeprom 6593 1 dvb_ttpci
soundcore 11681 1 snd
dvb_pll 18245 1 b2c2_flexcop
floppy 58661 0
snd_page_alloc 14281 2 snd_intel8x0,snd_pcm
ide_cd 40545 0
i2c_core 27841 12
eeprom,stv0297,bcm3510,lgdt330x,nxt200x,mt352,dvb_ttpci,stv0299,b2c2_flexcop,i2c_i801,ttpci_eeprom,dvb_pll
usbserial 35625 1 ftdi_sio
cdrom 37089 1 ide_cd
parport_pc 30821 1
e1000 118401 0
parport 38281 2 lp,parport_pc
serio_raw 10821 0
dm_snapshot 21093 0
dm_zero 6208 0
dm_mirror 25153 0
dm_mod 56833 13 dm_multipath,dm_snapshot,dm_zero,dm_mirror
ata_piix 18757 0
libata 120881 1 ata_piix
sd_mod 31297 0
scsi_mod 140621 2 libata,sd_mod
ext3 125641 4
jbd 59881 1 ext3
mbcache 12485 1 ext3
ehci_hcd 35661 0
ohci_hcd 23877 0
uhci_hcd 27089 0

---

Thank you. Sorry, for a long post.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Oliver Neukum]

Post by Ari Kohtamäki
ftdi_sio.c: ftdi_ioctl cmd 0x80046900
ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x80046900 - check
/usr/include/asm/ioctls.h

You need to find out what the unsupported ioctl is. Either use the file
indicated or strace your application.

Regards
Oliver


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Ari Kohtamäki]

OK. With strace I get:

writev(2, [{"lircd-0.8.1[4965]: accepted new "..., 52}, {"\n", 1}],
2lircd-0.8.1[4965]: accepted new client on /dev/lircd
) = 53
send(5, "<29>Jan 21 17:35:34 lircd-0.8.1["..., 72, MSG_NOSIGNAL) = 72
stat64("/dev/ttyUSB0", {st_mode=S_IFCHR|0666, st_rdev=makedev(188, 0), ...}) = 0
open("/dev/ttyUSB0", O_RDWR) = 7
ioctl(7, I2OGETIOPS, 0x8070648) = -1 EINVAL (Invalid argument)
time(NULL) = 1200929734
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
writev(2, [{"lircd-0.8.1[4965]: could not get"..., 50}, {"\n", 1}],
2lircd-0.8.1[4965]: could not get hardware features

So, its I2OGETIOPS which is not supported?

Terv. Ari

Post by Oliver Neukum

Post by Ari Kohtamäki
ftdi_sio.c: ftdi_ioctl cmd 0x80046900
ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x80046900 - check
/usr/include/asm/ioctls.h

You need to find out what the unsupported ioctl is. Either use the file
indicated or strace your application.
Regards
Oliver

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[David Brownell]

Post by Ari Kohtamäki
So, its I2OGETIOPS which is not supported?

No surprise ... why should any serial port understand such a thing?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Ari Kohtamäki]

Don't know, but it does when my remote receiver(/sender) is
plugged to my /dev/ttyS0:

write(2, "accepted new client on /dev/lirc"..., 33accepted new client
on /dev/lircd) = 33
write(2, "\n", 1
) = 1
stat64("/dev/lirc", {st_mode=S_IFCHR|0777, st_rdev=makedev(61, 0), ...}) = 0
open("/dev/lirc", O_RDWR) = 7
ioctl(7, I2OGETIOPS, 0x80625a8) = 0
time(NULL) = 1201025316
write(5, "Jan 22 20:08:36 dell.localdomain"..., 83) = 83
write(2, "lircd: ", 7lircd: ) = 7
write(2, "driver supports both sending and"..., 42driver supports both
sending and receiving) = 42

and now I can also send commands w/ my remote.
But that doesn't work with usb2serial plugin, but I'm working on it...
any tips on resolving are welcome. Using strace to debug was a good one.

Post by David Brownell

Post by Ari Kohtamäki
So, its I2OGETIOPS which is not supported?

No surprise ... why should any serial port understand such a thing?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Alex Villací­s Lasso]

Post by Ari Kohtamäki
Don't know, but it does when my remote receiver(/sender) is
write(2, "accepted new client on /dev/lirc"..., 33accepted new client
on /dev/lircd) = 33
write(2, "\n", 1
) = 1
stat64("/dev/lirc", {st_mode=S_IFCHR|0777, st_rdev=makedev(61, 0), ...}) = 0
open("/dev/lirc", O_RDWR) = 7
ioctl(7, I2OGETIOPS, 0x80625a8) = 0
time(NULL) = 1201025316
write(5, "Jan 22 20:08:36 dell.localdomain"..., 83) = 83
write(2, "lircd: ", 7lircd: ) = 7
write(2, "driver supports both sending and"..., 42driver supports both
sending and receiving) = 42

Please watch your strace carefully:

open("/dev/lirc", O_RDWR) = 7

This means that the program issued an open() system call on /dev/lirc
(NOT /dev/ttyS0), and received file descriptor 7 as a result.
Later on:

ioctl(7, I2OGETIOPS, 0x80625a8) = 0

The first parameter is the file descriptor (see ioctl(2) for details).
Remember that descriptor 7 results from opening /dev/lirc (as shown
earlier), NOT /dev/ttyS0. So the standard serial port does not
understand I2OGETIOPS either - /dev/lirc does (which is managed by the
LIRC kernel driver).
--
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Sergey Vlasov]

Post by Ari Kohtamäki
writev(2, [{"lircd-0.8.1[4965]: accepted new "..., 52}, {"\n", 1}],
2lircd-0.8.1[4965]: accepted new client on /dev/lircd
) = 53
send(5, "<29>Jan 21 17:35:34 lircd-0.8.1["..., 72, MSG_NOSIGNAL) = 72
stat64("/dev/ttyUSB0", {st_mode=S_IFCHR|0666, st_rdev=makedev(188, 0), ...}) = 0
open("/dev/ttyUSB0", O_RDWR) = 7
ioctl(7, I2OGETIOPS, 0x8070648) = -1 EINVAL (Invalid argument)
time(NULL) = 1200929734
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
writev(2, [{"lircd-0.8.1[4965]: could not get"..., 50}, {"\n", 1}],
2lircd-0.8.1[4965]: could not get hardware features
So, its I2OGETIOPS which is not supported?

This is really LIRC_GET_FEATURES - supported by the out-of-tree
lirc_dev driver (which will never work with USB-serial - however,
several USB IR receiver models are supported).

[Sergey Vlasov]

Post by Ari Kohtamäki
I have a CableStar 2 PCI DVB-C card with remote module.
When I attach the remote module (IR-receiver) to my
serial port it works OK with VDR using lirc.
I bought an usb2serial converter (FT232BM based) and
can't get my remote working with lirc at all. :(

Simple IR receivers for LIRC attached to a serial port won't work with
an USB-serial adapter. These receivers just pass IR pulses to a
serial control pin (e.g., DCD) and rely on the lirc_serial driver to
receive all signal transitions with precise timing (in microseconds);
this won't work over USB. So you need to find an USB IR receiver
which is supported by LIRC.

Another option is to get a PCI (or PCI-Express) serial port card - it
might work with lirc_serial, if it is compatible with 16550 and uses
IO port mapping (some of these devices are using memory-mapped
registers - they won't work without code changes in lirc_serial).
However, such configuration is not supported by lirc_serial directly
(in particular, lirc_serial wants to get IO port address in its module
parameters, and addresses for PCI devices are dynamic and may change
between boots).