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 desti
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
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
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
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
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 getpar
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
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
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? (a
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 ab
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?
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
frameb
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 is
Helge Hafting wrote:
From the [ruby patch] documentation:
The main problem up to this date (November 2004) is that linux kernel
has only one behaviour regarding multiple keyboards : any key pressed
catched on any keyboard is redirected to the one and only active
Virtual Terminal (VT).
Will this
Michel DÃnzer 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 so
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
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
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
Ian Romanick wrote:
Tomas Carnecky wrote:
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
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 low/high
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 ?
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 dr
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) G
24 matches
Mail list logo