On 01/09/2009 06:32 PM, Jesse Barnes wrote:
Oh, don't use the modesetting-gem branch anymore. The master branch of the
drm tree has all the libdrm bits you need, and Linus' git tree has the kernel
mode setting bits you need (even better would be to use Eric's tree, it has a
few fixes destined
On 01/09/2009 01:31 PM, Abraham Varricatt wrote:
Hi guys,
I recently obtained source of the DRM package from,
git://git.freedesktop.org/git/mesa/drm
I move to the drm directory on my system and run the following commands,
./autogen --prefix=$HOME/install
make
make –C linux-core
This
On 01/09/2009 04:50 PM, Sergio Monteiro Basto wrote:
On Fri, 2009-01-09 at 14:04 +0100, Tomas Carnecky wrote:
The kernel modules are now being developed entirely within the
kernel.
Get the kernel source and build the drm module from there.
Can I build just the drm modules ?
if yes how I do
On 12/04/2008 05:16 AM, Keith Packard wrote:
On Thu, 2008-12-04 at 02:44 +0100, Pierre Willenbrock wrote:
Not looping in the irq-handler seems to work (so far, at least).
Excellent. Looping should only be required when using MSI. Let's try to
get a few more people to report back before we
On 12/05/2008 01:54 AM, Keith Packard wrote:
On Thu, 2008-12-04 at 15:43 +0100, Tomas Carnecky wrote:
Should I apply both patches or only the second one (the one that adds
the 'break;')? I applied both and I was still getting the IRQ storms.
This is also on a GM965.
It shouldn't have
Keith Whitwell wrote:
Major bumps once stuff went into the kernel weren't allowed at all.
You'd need to fork the driver in any case. So we did this once or
twice on drivers in devel trees like mach64.
However upstream first policy should avoid this need. I'd also prefer
to see getparam for
Steven J Newbury wrote:
On Wed, 2008-06-25 at 21:14 +0100, Steven J Newbury wrote:
On Wed, 2008-06-25 at 20:03 +0100, Steven J Newbury wrote:
On Wed, 2008-06-25 at 11:30 -0700, Jesse Barnes wrote:
On Wednesday, June 25, 2008 10:28 am Steven J Newbury wrote:
On Wed, 2008-06-25 at 16:29 +0100,
Johannes Engel wrote:
Thomas Hellström wrote:
Johannes,
If the patch works, it looks correct to me.
However, you need to make sure (using defines) that the code will
compile also on kernels that don't have the .fault method.
/Thomas
Hi Thomas,
thanks for reviewing and suggesting. :)
I have read (don't remember where) that once the kernel has a sensible
infrastructure for file descriptors you'd want to convert all the ioctl
code in GEM/TTM to standard syscalls. Is that true? Do you already know
which syscalls would replace for example drmBOCreate() or the GEM_CREATE
ioctl?
Keith Whitwell wrote:
The DRI list has in effect become the list for development of the drm
kernel module, libdrm, and the various memory manager implementations.
While Mesa is an important client of these, it is far from being the
only client.
Interesting. Who else is a client of drm?
Felix Kühling wrote:
Am Sa, den 18.12.2004 schrieb Tomas Carnecky um 14:54:
Most (all?) supported hardware doesn't support multiple clipping
rectangles in hardware, so the driver iterates over them and draws all
primitives once in each clipping rectangle.
Quite CPU expensive, isn't it?
It seems
Felix Kühling wrote:
Am So, den 19.12.2004 schrieb Tomas Carnecky um 15:32:
Who exactly does map the memory? The Xserver or the DRM library? If it's
the Xserver, how can it know where all the different buffers are?
I'm not sure I understand the question. I'll rephrase the above and hope
Tomas Carnecky wrote:
Hi,
Can I control a graphics card _completely_ with DRI? I mean
allocate the framebuffer, switch between modes etc. Or do I
need some kind of helper code that does these things (like
fbdev or the Xserver)?
I'm particulary interested in allocating memory for the
framebuffer
Hi,
Can I control a graphics card _completely_ with DRI? I mean
allocate the framebuffer, switch between modes etc. Or do I
need some kind of helper code that does these things (like
fbdev or the Xserver)?
I'm particulary interested in allocating memory for the
framebuffer via DRI, I think there
David Bronaugh wrote:
Tomas Carnecky wrote:
David Bronaugh wrote:
Another option would be to design a generic, more low-level wrapper
for graphics hardware. In my opinion this is a huge undertaking (ever
read chip docs? You try integrating 3000 pages of information (that
would be around 5
Mike Mestnik wrote:
I think every thing Tomas Carnecky has said here about device driver
design is valid and dose apply to the DRM/dri. He may not know every
thing about system security, but we also all have our strangths and his
strangth is oviously device design. One way of interpeting what
Michel Dnzer wrote:
The userspace dri driver is the only user of these kernel drivers.
No, there's also the DDX drivers, XvMC, ... and there could be more in
the future.
So you tell me that there are at least three (DRI/DDX/XvMC) libraries
which do basically the same thing?
If, and that's what
Why are the DRM() macros used in the linux kernel drivers?
I'm sure this has been discussed many times, but I can't find
anything about it.
Any explanations or pointers to webpages (archives) where it's
explained are welcome.
Thanks
--
wereHamster a.k.a. Tom Carnecky Emmen, Switzerland
(GC 3.1)
Ian Romanick wrote:
Tomas Carnecky wrote:
Why are the DRM() macros used in the linux kernel drivers?
I'm sure this has been discussed many times, but I can't find
anything about it.
Any explanations or pointers to webpages (archives) where it's
explained are welcome.
Each DRM driver contains
As it seems, there is the required code for managment of drawables
within the drivers, but noone seems to use it (drm_drawable.h).
Any reason for that? (I mean for not using it).
--
wereHamster a.k.a. Tom Carnecky Emmen, Switzerland
(GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O
The dri/drm interface seems to be quite low-level. I heard somewhere
that different devices have quite different registers and work in a
quite different way. If it is true that it would be better to make a
more high-level interface where every driver can do it's stuff as it
needs. How much
David Bronaugh wrote:
A device driver is not just a wrapper around the device which gives you
access to the registers. Even the core components of your computer have
a nice interface (your harddisk controller: open/read/write/close etc).
You're speaking of a generic interface to the hardware. The
22 matches
Mail list logo
