All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Mort <garyamort@gmail.com>
To: LMML <linux-media@vger.kernel.org>
Cc: linux-usb@vger.kernel.org
Subject: [RFC] Using UVC as a monitor
Date: Tue, 15 Oct 2013 10:15:23 -0400	[thread overview]
Message-ID: <525D4DFB.9080806@gmail.com> (raw)

I'm pulling together code at the moment which I'll post for comment 
later in the week.

What I want to do is combine the operations of 2 drivers to create a 
virtual monitor via UVC, uvcfbsource

It involves configuring the UVC video-streaming capability of the USB 
Webcam Gadget to use a framebuffer as it's source.

The SimpleFB driver currently in the kernel requires the framebuffer 
memory to be allocated by some other program/driver - so it seems a good 
choice for the framebuffer.

Using the current capabilities of the USB webcam gadget, it seems for a 
simple solution all I need to do is have a userspace application which 
grabs the framebuffer data, wraps it into a videobuf2 format and inserts 
it into the queue.

In this mode, the "Monitor" becomes any application capable of 
displaying streaming video - for that matter, if multiple instances of 
the userspace application are executed then you can have multiple 
monitors all displayed on the same computer.

Purpose: I am working with a couple of ARM development boards, primarily 
the BeagleBoneBlack.  Using a usb montor gadget, I can give my BBB a 
monitor without actually having to plug in a monitor.

In simple mode, the framebuffer would be configured with a resolution of 
720p and to store data in the YUV format so it matches one of the 
currently defined formats in the Webcam gadget.

Beyond that though, I'd like to extend this to a smarter kernel driver 
which could:
1) Use the start streaming/stop streaming USB events to emulate 
hotplugging the monitor.
2) Allow for different resolutions to be supported and controlled by the 
remote computer[IE show different options, and allow the webcam viewer 
application to choose one of the streams]
3) Allow for the complete set of UVC supported YUV formats for frames
4) Switch from the video stream UVC encapsulation to the frame buffer stream

Using UVC in this manner has the downside that full uncompressed frame 
data is being transmitted over USB - however UVC does provide a number 
of optional compression and encoding methods - so it's possible to 
improve performance if there is demand for it.  It is also possible to 
use 'vendor defined' compression and encoding methods if those are not 
sufficient.   Since UVC allows the gadget to advertise multiple 
capabilities - a device using the uvcfbsource driver could be used by 
any system supporting standard Webcams - Mac, Windows, Android, Linux, 
etc via the uncompressed format - while the compressed format can be 
used if the viewer application supports it.

I wanted to check now to see if there is something I'm missing, or known 
projects already working on this sort of thing, before I start coding.

My long term goal is to use the code developed for a fully functional 
uvcfbsink driver to create a uvcfbsource driver: ie an application which 
reverses the process and receives data from a uvc "webcam" and pushes it 
into a framebuffer.  That would allow for creating an open source 
alternative to DisplayLink while avoiding any usage of their API and any 
potential patent issues.


-Gary







                 reply	other threads:[~2013-10-15 14:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=525D4DFB.9080806@gmail.com \
    --to=garyamort@gmail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.