Re: Question regarding linux1394 and bug report
Brought to you by:
aeb,
bencollins
From: Takashi S. <o-t...@sa...> - 2024-01-05 15:02:44
|
Hi, On Fri, Jan 05, 2024 at 02:13:00PM +0200, Tasos Sahanidis wrote: > Hi Takashi, > > Thank you for your work in the Linux FireWire subsystem, and apologies > for this direct email. > > About a year ago I sent an email [0] to the linux1394 (user) mailing > list with a bug report but received no response. I've been subscribed to > linux1394-devel as well since and I've seen that it is now active. > > I remember reading that there is a no cross-posting rule, thus I haven't > re-sent my message to linux1394-devel. I have access to this hardware > again, and will do for about the next two weeks. > > Is this something you'd be interested in helping me with? If so, do you > want me to re-send the e-mail to linux1394-devel and continue the > conversation there? The issue still occurs on Ubuntu 22.04 with kernel > 6.6.9. > > Thank you for your time and looking forward to your response. > > -- > Tasos > > [0] https://sourceforge.net/p/linux1394/mailman/message/37766465/ I'm not good at any type of video protocol over IEEE 1394, thus less help to your issue, sorry. As a quick glance, you need to identify the direct cause of your issue that dvgrab never receives video data at recent version of kernel at first, then go to investigate kernel implementation if needed. In my opinion, the best way is to investigate whether dvgrab (and libavc1394) can operate your hardware to transfer isochronous packet to your system. For example, you have dumped the part of communication between dvgrab and your hardware for AV/C commands. You can interpret them according to specification specific to tape recorder and player protocol. You can see two documents in 1394TA site archived by internet-archive project[1]. * AV/C Digital Interface Command Set General Specification Version 4.2 (2004006) * AV/C Tape Recorder/Player Subunit Specification 2.4 (2004005) Below communication expresses: ``` firewire_ohci: AT spd 0 tl 2a, ffc1 -> ffc0, ack_complete, QW req, fffff0000b00 = 0120d07f firewire_ohci: AR spd 0 tl 2a, ffc0 -> ffc1, ack_pending , QW req, fffff0000d00 = 0c20c460 firewire_ohci: AT spd 0 tl 2a, ffc1 -> ffc0, ack_complete, W resp ``` [dvgrab -> hardware] 0x01: command type: status 0x20: subunit type/id: tape recorder/player 0xd0: opcode: transport state: 0x7f: operand[0]: 0x7e [hardware -> dvgrab] 0x0c: response: stable 0x20: subunit type/id: tape recorder/player 0xc4: opcode: transport_mode: wind 0x60: operand[0]: transport_state: stop Below communication expresses: ``` firewire_ohci: AT spd 0 tl 2d, ffc1 -> ffc0, ack_complete, QW req, fffff0000b00 = 0020c375 firewire_ohci: AR spd 0 tl 2d, ffc0 -> ffc1, ack_pending , QW req, fffff0000d00 = 0920c375 firewire_ohci: AT spd 0 tl 2d, ffc1 -> ffc0, ack_complete, W resp ``` [dvgrab -> hardware] 0x00: command type: control 0x20: subunit type/id: tape recorder/player 0xc3: opcode: play 0x75: operand[0]: playback_mode: forward [hardware -> dvgrab] 0x09: response: accepted 0x20: subunit type/id: tape recorder/player 0xc3: opcode: play 0x75: operand[0]: playback_mode: forward I expect that if dvgrab takes the hardware to be prepared, it keeps isochronous resources by operating both CHANNEL_AVAILABLE registers (0xfffff0000224-0228) and BANDWIDTH_AVAILABLE register (0xfffff0000220), and operate plug control registers (0xfffff0000900-0904) according to IEC 61883-1. Then the hardware start transmission of isochronous packets, defined in IEC 61883-1 and -2/-3/-5. [1] https://web.archive.org/web/20200204014929/1394ta.org/specifications/ Regards Takashi Sakamoto |