Hello dri-users,
you can now download the first experimental snapshots built from Xorg
CVS. There are also new snapshots available for Via (unichrome) and i915
chips. Download from
http://freedesktop.org/~fxkuehl/snapshots
Pick the snapshots labeled -20041003-linux.i386.tar.bz2. Please
install
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
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1511
--- Additional Comments From [EMAIL PROTECTED] 2004-10-03 20:19 ---
Fix committ
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
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1519
--- Additional Comments From [EMAIL PROTECTED] 2004-10-03 18:53 ---
Created an
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1519
Summary: Enabling Anisotropy Locks r200 Driver
Product: DRI
Jon Smirl wrote:
On Fri, 01 Oct 2004 10:49:14 -0700, Ian Romanick <[EMAIL PROTECTED]> wrote:
Jon Smirl wrote:
Maybe we should fork linux-core into linux-core-2.4 and linux-core-2.6
before it drifts too far from being able to run on 2.4. I suspect
linux-core would compile on 2.4 right now with minor
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
On Sun, 2004-10-03 at 04:36, Felix Kühling wrote:
> This commit brings up a problem with building bleeding-edge Mesa drivers
> in the Xorg tree. Since Xorg still has its own version of Mesa we can't
> just change the Imakefiles in xc/lib/GL/mesa/drivers/dri/... as that
> would break the build for e
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
This commit brings up a problem with building bleeding-edge Mesa drivers
in the Xorg tree. Since Xorg still has its own version of Mesa we can't
just change the Imakefiles in xc/lib/GL/mesa/drivers/dri/... as that
would break the build for everybody else. I guess the solution is to
always build 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.
21 matches
Mail list logo
