[gstreamer-bugs] [Bug 612244] v4l2sink updates

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=612244
  GStreamer | gst-plugins-good | git

--- Comment #16 from Rob Clark <rob at ti.com> 2010-03-23 13:37:18 UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > (In reply to comment #12)
> > > > (From update of attachment 155587 [details] [details] [details] [details])
> > > > Should this and the next patch be somehow conditional with a #ifdef OMAP
> > > > somehow?
> > > 
> > > It could be.. but I figured if the majority of devices using v4l2sink were
> > > OMAP, then it might as well work out of the box.  I could add an --enable-omap
> > > or something like that to configure.ac, but that seemed overkill.
> > 
> > Okay, I was just wondering how to clearly mark such hardware specific
> > workarounds, so that they are manageable in the long run.
> 
> I'm open to suggestions..  I could mark them w/ a specific comment tag or
> something like this?
> 
> so far I was happy to manage to keep the work-arounds limited to a single
> function ;-)

fwiw, these two patches (omap24xxvout and omap_vout driver support) could be
moved to a different bugzilla ticket with some minor rebasing if this is
preferred.

I'm still interested if there is some precedent for work-arounds for various
different existing drivers in other code?  I'd kinda like it for things to work
out-of-the-box for people on embedded platform, but I'm not really sure how to
test for which driver it will be in configure script..

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.