Jon Smirl wrote:
On Sun, 3 Oct 2004 11:38:39 -0700 (PDT), Mike Mestnik
<[EMAIL PROTECTED]> wrote:
What about moving the DRM and FB specific code into there own per card
libs?
radeon - attached to hardware
radeon-drm
drm - library
radeon-fb
fb - library
fbcon - library
Fell fr
On Mon, 4 Oct 2004 19:47:00 +0200, Tonnerre <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 03, 2004 at 12:46:51PM -0400, Jon Smirl wrote:
> > But there does appear to be one other user of inter_module_...
> > MTD driver for "M-Systems Disk-On-Chip Millennium Plus"
> > mtd/devices/doc2001plus.c
> > mtd/ch
Salut,
On Sun, Oct 03, 2004 at 12:46:51PM -0400, Jon Smirl wrote:
> But there does appear to be one other user of inter_module_...
> MTD driver for "M-Systems Disk-On-Chip Millennium Plus"
> mtd/devices/doc2001plus.c
> mtd/chips/cfi_cmdset_0001.c
nvidia and ati use them as well, it seems. Not
On Sul, 2004-10-03 at 23:42, Jon Smirl wrote:
> Is there are device driver level interface defined for controlling
> tuners?
Both at the Xv and the kernel level yes.
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
On Sun, 3 Oct 2004, Alan Cox wrote:
On Sul, 2004-10-03 at 16:50, Vladimir Dergachev wrote:
In particular, I can contribute the code that does Framebuffer->System Ram
transfers over PCI/AGP. It is currently GPL licensed, but there is no
problem if BSD folks want it too.
This will do *wonders* to X
On Sul, 2004-10-03 at 16:50, Vladimir Dergachev wrote:
> In particular, I can contribute the code that does Framebuffer->System Ram
> transfers over PCI/AGP. It is currently GPL licensed, but there is no
> problem if BSD folks want it too.
This will do *wonders* to X render performance if used pr
Is there are device driver level interface defined for controlling
tuners? Or is this something that even needs to be done in a device
driver? With X on GL Xv will have to change form too.
On Sun, 3 Oct 2004 16:37:03 -0400 (EDT), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 3 Oct
On Sun, 3 Oct 2004, Jon Smirl wrote:
How is the tuner controlled? Is it a V4L insterface?
No, the tuner is controlled via Xserver Xv extension. No V4L interface is
provided for tuner control.
best
Vladimir Dergachev
On Sun, 3 Oct 2004 12:59:38 -040
What about moving the DRM and FB specific code into there own per card
libs?
radeon - attached to hardware
radeon-drm
drm - library
radeon-fb
fb - library
fbcon - library
Keeping in mind that any/all external symbols to/from radeon-drm and
radeon-fb can/should be weak.
On Sun, 3 Oct 2004 11:38:39 -0700 (PDT), Mike Mestnik
<[EMAIL PROTECTED]> wrote:
> What about moving the DRM and FB specific code into there own per card
> libs?
>
> radeon - attached to hardware
>radeon-drm
> drm - library
>radeon-fb
> fb - library
> fbcon - library
How is the tuner controlled? Is it a V4L insterface?
On Sun, 3 Oct 2004 12:59:38 -0400 (EDT), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
> Jon, this is a common misconception - GATOS km module *does* provide a v4l
> interface.
>
> What is different is that the device configuration (like setti
On Sun, 3 Oct 2004 08:26:54 +0100 (IST), Dave Airlie <[EMAIL PROTECTED]> wrote:
> I also want to prepare some patches for the kernel for the previous work
> you've done ...
Did you get around to making ffb compile?
Have all of the drivers been given minimal testing? I've done radeon and r128.
Is
km - library
Libraries are kernel modules that don't attach to any specific
hardware, they just supply routines for other drivers to call. We
might want to change the name of these to libdrm, libfb, libkm.
I haven't looked into Gatos yet but I'd like to see the radeon
converted to follow the mode
On Sun, 3 Oct 2004 11:50:50 -0400 (EDT), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
> On Sun, 3 Oct 2004, Jon Smirl wrote:
>
> > If we could all just concentrate on fixing the radeondrm driver we
> > could build a complete driver for the radeon cards instead of the ten
> > half finished ones we
On Sun, 3 Oct 2004, Jon Smirl wrote:
If we could all just concentrate on fixing the radeondrm driver we
could build a complete driver for the radeon cards instead of the ten
half finished ones we have today. Once we get a complete driver the
incentive for people to write new ones will be gone.
M
Resource reservations are not the central problem with merging fbdev
and drm. The central problem is that both card specific drivers
initialize the hardware, program it in conflicting ways, allocate the
video memory differently, etc. Moving to a single card specific driver
lets me fix that.
In the
> In this model a non-drm, fb only driver like cyber2000 could load only
> the fb and fbcon modules. I need to do some work rearranging generic
> library support functions to allow this.
>
I think the stated issue with this is, how big the fb driver now becomes
because all the DRM stuff is in it.
I've started on a merged fbdev and DRM driver model.
It doesn't work yet but here's what the modules look like:
Module Size Used by
fbcon 38080 0
radeon123598 1
fb 34344 2 fbcon,radeon
drm59044 1 radeon
18 matches
Mail list logo
