On Sat, May 29, 2010 at 6:06 AM, Ville Syrjälä syrj...@sci.fi wrote:
On Fri, May 28, 2010 at 03:41:46PM -0400, Alex Deucher wrote:
On Fri, May 28, 2010 at 3:15 PM, Florian Tobias Schandinat
If he wants different (independent) content on each output, just provide
multiple /dev/fbX devices. I
On Thu, 27 May 2010, Alex Deucher wrote:
On Thu, May 27, 2010 at 2:56 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
...
Ok, let me explain what exactly I meant. Above I referred to display
drivers, which is not the same as a framebuffer controller driver or
whatever you would
(re-adding lists to CC)
On Thu, 27 May 2010, Rob Clark wrote:
Hi Guennadi,
Sounds like an interesting idea... but how about the inverse? A v4l2
interface on top of fbdev. If v4l2 was more widely available as an output
device, perhaps more userspace software would utilize it.
Don't see
On Fri, May 28, 2010 at 4:21 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
On Thu, 27 May 2010, Alex Deucher wrote:
On Thu, May 27, 2010 at 2:56 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
...
Ok, let me explain what exactly I meant. Above I referred to display
Alex Deucher schrieb:
On Fri, May 28, 2010 at 4:21 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
On Thu, 27 May 2010, Alex Deucher wrote:
Another API to consider in the drm kms (kernel modesetting) interface.
The kms API deals properly with advanced display hardware and
properly
On Fri, 28 May 2010, Florian Tobias Schandinat wrote:
Well hiding complexity is actually the job of an API. I don't see any need for
major changes in fbdev for complex display setups. In most cases as a
userspace application you really don't want to be bothered how many different
output
On Fri, May 28, 2010 at 3:15 PM, Florian Tobias Schandinat
florianschandi...@gmx.de wrote:
Alex Deucher schrieb:
On Fri, May 28, 2010 at 4:21 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
On Thu, 27 May 2010, Alex Deucher wrote:
Another API to consider in the drm kms (kernel
Guennadi Liakhovetski schrieb:
On Fri, 28 May 2010, Florian Tobias Schandinat wrote:
Well hiding complexity is actually the job of an API. I don't see any need for
major changes in fbdev for complex display setups. In most cases as a
userspace application you really don't want to be bothered
On Fri, May 28, 2010 at 03:41:46PM -0400, Alex Deucher wrote:
On Fri, May 28, 2010 at 3:15 PM, Florian Tobias Schandinat
If he wants different (independent) content on each output, just provide
multiple /dev/fbX devices. I admit that we could use a controlling interface
here that decides
-Original Message-
From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev-
ow...@vger.kernel.org] On Behalf Of Guennadi Liakhovetski
Sent: Wednesday, May 26, 2010 7:40 PM
To: linux-fb...@vger.kernel.org
Subject: Idea of a v4l - fb interface driver
This message has been
(adding V4L ML to CC and preserving the complete reply for V4L readers)
On Thu, 27 May 2010, Jaya Kumar wrote:
On Wed, May 26, 2010 at 10:09 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Problem: Currently the standard way to provide graphical output on various
(embedded) displays
On Thu, 27 May 2010, Hiremath, Vaibhav wrote:
OTOH V4L2 has a standard video output driver support, it is not very
widely used, in the userspace I know only of gstreamer, that somehow
supports video-output v4l2 devices in latest versions. But, being a part
of the v4l2 subsystem, these
On Thu, May 27, 2010 at 2:56 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
(adding V4L ML to CC and preserving the complete reply for V4L readers)
On Thu, 27 May 2010, Jaya Kumar wrote:
On Wed, May 26, 2010 at 10:09 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Ok, let me
On Thu, 27 May 2010, Jaya Kumar wrote:
You've raised the MIPI-DSI issue. It is a good area to focus the
discussion on for fbdev minded people and one that needs to be
resolved soon so that we don't get dozens of host controller specific
mipi display panel drivers. I had seen that omap2 fbdev
Am 27.05.2010 08:44, schrieb Hiremath, Vaibhav:
V4L(2) video output vs. framebuffer.
Problem: Currently the standard way to provide graphical output on various
(embedded) displays like LCDs is to use a framebuffer driver. The
interface is well supported and widely adopted in the
On Thu, May 27, 2010 at 2:56 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
(adding V4L ML to CC and preserving the complete reply for V4L readers)
On Thu, 27 May 2010, Jaya Kumar wrote:
On Wed, May 26, 2010 at 10:09 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Problem:
16 matches
Mail list logo
