Bug 101450 - multimedia/transcode: tcprobe broken for devfs
Summary: multimedia/transcode: tcprobe broken for devfs
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-06 01:20 UTC by Chad Fraleigh
Modified: 2011-11-06 15:49 UTC (History)
0 users

See Also:


Attachments
transcode.diff (2.03 KB, patch)
2006-10-22 20:57 UTC, Stanislav Sedov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chad Fraleigh 2006-08-06 01:20:07 UTC
tcprobe fails on CD/DVD devices. The transcode 1.0.2_3 port uses device
major numbers to determine how to use a device path. With devfs no longer
using well known major device numbers, the function used to identify it
thinks all devices are OSS (major 0).

The broken code is in import/ioaux.c:probe_path():

# ifdef __FreeBSD__
              case 4: /* acd */
                  return(TC_PROBE_PATH_ABSPATH);
              case 229: /* bktr */
                  return(TC_PROBE_PATH_BKTR);
              case 0: /* OSS */
                  return(TC_PROBE_PATH_OSS);
# endif

This causes an indirect error with tcprobe (which also effects the dvdrip
port) when it attempts to do an SNDCTL_DSP_GETFMTS ioctl() [misreported in
the error message as SNDCTL_DSP_SETFMT].

OpenBSD may also be affected if it has, or plans to, make simular device
changes (in case any one cross project monitoring is reading this).

Fix: 

Abstact: Determine reliable method to distinguish between CD/DVD, BKTR, OSS,
and other devices and add approriete patch to the port and/or submit to
original authors.

Possibly even adding a warning message to the port during installation so
that users know it is broken in this respect, until a real fix can be made.
How-To-Repeat: % tcprobe -i /dev/acd0
[tcprobe] OSS audio device
SNDCTL_DSP_SETFMT: Inappropriate ioctl for device
[tcprobe] failed to probe source


% tcprobe -i /dev/null
[tcprobe] OSS audio device
SNDCTL_DSP_SETFMT: Inappropriate ioctl for device
[tcprobe] failed to probe source
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2006-08-29 23:52:16 UTC
State Changed
From-To: open->feedback

To which part of the system does this PR apply? 


Comment 2 Mark Linimon freebsd_committer freebsd_triage 2006-08-29 23:52:16 UTC
Responsible Changed
From-To: freebsd-bugs->linimon

Track.
Comment 3 Chad Fraleigh 2006-08-30 00:51:22 UTC
 	This should have been 'ports'.

 	I initially select this, but waited too long and my session 
expired, then forgot to set it again when copying everything back in to 
the new form.
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2006-08-30 02:25:08 UTC
State Changed
From-To: feedback->open

Make a ports PR and assign. 


Comment 5 Mark Linimon freebsd_committer freebsd_triage 2006-08-30 02:25:08 UTC
Responsible Changed
From-To: linimon->freebsd-ports-bugs
Comment 6 Stanislav Sedov freebsd_committer freebsd_triage 2006-10-21 10:46:00 UTC
Responsible Changed
From-To: freebsd-ports-bugs->stas

I'll take it.
Comment 7 Stanislav Sedov freebsd_committer freebsd_triage 2006-10-22 20:57:45 UTC
Hi!

Are you agreed with the patch attached?

-- 
Stanislav Sedov          <stas@FreeBSD.org>        [[òÏÓÓÉÑ, íÏÓË×Á]]
PGP id: 0xEB269581       http://people.freebsd.org/~stas/stas.key.asc
Comment 8 Chad Fraleigh 2006-10-31 02:39:11 UTC

On Sun, 22 Oct 2006, Stanislav Sedov wrote:

> Hi!
>
> Are you agreed with the patch attached?
>
> -- 
> Stanislav Sedov          <stas@FreeBSD.org>        [[òÏÓÓÉÑ, íÏÓË×Á]]
> PGP id: 0xEB269581       http://people.freebsd.org/~stas/stas.key.asc
>


 	It seems to work for me. However, I can see it may still cause 
other people problems if they use symlinks for those devices.

 	An idea I had for this problem (which goes far beyond the scope of 
this bug) would be to introduce a general file descriptor ioctl to the OS 
(unless it's been done). Basically it would be similar to the USB device 
descriptor which provides a type class (and sub-class). For the case of 
files/devices it could have a class and sub-class and/or feature flags 
(with in the context of the main class). Personally I think a sub-class 
may be unnecessary and less useful than a features list. But unlike a USB 
descriptor values that are limited to 8-bits, the sub-class could be 
replaced with a 32 or 64 bit value that is mapped to a specific unique 
device or API type. And just for good measure allow for multiple class 
types for composite drivers that use a single device entry (if it's an 
issue).

 	Here is a rough example of a hypothetical return structure:

 	struct
 	{
 		unsigned long	tid;		/* optional specific type-id */
#define	FDTID_CMI8738		0x06519903L
#define	FDTID_OHCI		0x85398652L

 		unsigned	nclasses;

 		/* Most significant/primary entry first for simple queries */
 		struct
 		{
 			unsigned int	fd_class;
#define	FDCLASS_AUDIO	0x00000003	/* Audio I/O */
#define	FDCLASS_VIDEO	0x00000200	/* Display (Capture?) */
#define	FDCLASS_NIC	0x00000081	/* Network Card	*/
#define	FDCLASS_FILE	0x00000028	/* Regular File	*/
#define	FDCLASS_NETWORK	0x00000004	/* Socket */

 			unsigned int	fd_features;
#define	FDFEAT_AUDIO_WAVE	0x00000001	/* Supports wave data */
#define	FDFEAT_AUDIO_PLAY	0x00000002	/* Output */
#define	FDFEAT_AUDIO_RECORD	0x00000004	/* Input */

#define	FDFEAT_VIDEO_FRAMEBUFFER	0x00000001
#define	FDFEAT_VIDEO_OVERLAY		0x00000002

#define	FDFEAT_FILE_LOCAL	0x00000001

#define	FDFEAT_NETWORK_STREAM	0x00000001
 		} centries[1];
 	} fdesc_descriptor_t;



-Chad
Comment 9 dfilter service freebsd_committer freebsd_triage 2007-01-03 11:28:05 UTC
stas        2007-01-03 11:27:48 UTC

  FreeBSD ports repository

  Modified files:
    multimedia/transcode Makefile 
  Added files:
    multimedia/transcode/files patch-import_ioaux.c 
  Log:
  - Fix detecting of device types
  
  Currently, this patch handles all devfs cases (it uses realpath to resolve
  symlinks). However, submitter supposes, that we should have a generic way
  to detect which device the file belongs to. I'll leave the PR in suspended
  state for a better solution come up.
  
  PR:             ports/101450
  Reported by:    Chad Fraleigh <chadf@bookcase.com>
  Approved by:    multimedia (ahze)
  
  Revision  Changes    Path
  1.81      +1 -1      ports/multimedia/transcode/Makefile
  1.1       +43 -0     ports/multimedia/transcode/files/patch-import_ioaux.c (new)
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 10 Stanislav Sedov freebsd_committer freebsd_triage 2007-01-03 11:28:56 UTC
State Changed
From-To: open->suspended

-  Suspend until a better solution will be implemented
Comment 11 Thomas Abthorpe freebsd_committer freebsd_triage 2011-11-05 04:11:20 UTC
Responsible Changed
From-To: stas->freebsd-ports-bugs

- back to the heap
Comment 12 Martin Wilke freebsd_committer freebsd_triage 2011-11-06 15:49:28 UTC
State Changed
From-To: suspended->closed

seems that was committed 3 Jan 2007. i close that here.