On Sat, 18 Jun 2005, Johannes Berg wrote:
Hi,
I just tried the latest r300 cvs code (with current mesa cvs, latest
Xorg snapshot) but all I get is a lockup as soon as the X server starts.
If I have debugging enabled, I get a loop of radeon_do_cp_idle calls.
Hardware is:
:00:10.0 VGA comp
Looking at driver/server all of the drivers are effectively creating
an sarea of size SAREA_MAX. I also grepped through x.org and could not
find any place where it is set to anything besides SAREA_MAX. There is
code that sets it to other values but it is ifdef'd out.
x.org ifdef's have this commen
From: Nishanth Aravamudan <[EMAIL PROTECTED]>
Rather than use custom code in DRM_WAIT_ON() to do exactly
what wait_event_interruptible_timeout() does, use the function and just
change the return values appropriately.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Pu
On 20.06.2005 [23:48:22 +0100], Dave Airlie wrote:
>
> I already NAK'ed this patch, it breaks things.. so hardly janitorial stuff
> really...
>
> On Mon, 20 Jun 2005 [EMAIL PROTECTED] wrote:
>
> > From: Nishanth Aravamudan <[EMAIL PROTECTED]>
> >
> >
> >
> > Rather than use custom code in DRM_WA
On 20/06/05 15:52 -0700, Nishanth Aravamudan wrote:
> On 20.06.2005 [23:48:22 +0100], Dave Airlie wrote:
> >
> > I already NAK'ed this patch, it breaks things.. so hardly janitorial stuff
> > really...
> >
> > On Mon, 20 Jun 2005 [EMAIL PROTECTED] wrote:
> >
> > > From: Nishanth Aravamudan <[EMA
I already NAK'ed this patch, it breaks things.. so hardly janitorial stuff
really...
On Mon, 20 Jun 2005 [EMAIL PROTECTED] wrote:
> From: Nishanth Aravamudan <[EMAIL PROTECTED]>
>
>
>
> Rather than use custom code in DRM_WAIT_ON() to do exactly
> what wait_event_interruptible_timeout() does, use
Ian Romanick wrote:
The problem with the SAREA is that user-mode can request an SAREA
*larger* than the kernel knows about. For example, the user-mode
drivers can add extra fields for the DDX and client-side drivers to
communicate. The kernel doesn't need to know anything about what's in
that
On 6/20/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sad, 2005-06-18 at 16:54, Jon Smirl wrote:
> > How about this as a safe first step:
> > 1) Remove the general root capability check
> > 2) Change the semantics of the root_only field on these calls to mean
> > master only.
> > 3) Push the root ca
On 6/20/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> The problem with the SAREA is that user-mode can request an SAREA
> *larger* than the kernel knows about. For example, the user-mode
> drivers can add extra fields for the DDX and client-side drivers to
> communicate. The kernel doesn't need t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan Cox wrote:
> On Sad, 2005-06-18 at 23:30, Adam Jackson wrote:
>
>>The issue is that drmAddMap, the function that sets up these maps, is
>>currently run from the server during DDX bringup. These maps can just as
>>easily be created during DRM i
> I very strongly believe that the right model moving forward is for
> user-mode to say to the kernel, "I beg of thee. Initialize thyne self."
Much of the initialization of chips is complex and messy and not
neccessarily good kernel material. SAREA setup I agree seems an obvious
kernel thing to d
On Sad, 2005-06-18 at 16:54, Jon Smirl wrote:
> How about this as a safe first step:
> 1) Remove the general root capability check
> 2) Change the semantics of the root_only field on these calls to mean
> master only.
> 3) Push the root capability check into each of these IOCTL individually.
> 4) L
On Sad, 2005-06-18 at 20:22, Jon Smirl wrote:
> Then this is a card by card problem. If user space needs to get to the
> registers, and we can't split the safe registers from the unsafe
> (security issues) ones, then the user space drivers also needs to run
> as root.
Incorrect. See the via driver
On Sad, 2005-06-18 at 23:30, Adam Jackson wrote:
> The issue is that drmAddMap, the function that sets up these maps, is
> currently run from the server during DDX bringup. These maps can just as
> easily be created during DRM init - and as a design issue, probably _should_
> be created there.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicolai Haehnle wrote:
> I don't see any reason for mapping registers into userspace in the first
> place. Except for mode setting and related setup tasks (which aren't
> exactly performance critical), you'll never want to write to registers
> dire
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jon Smirl wrote:
> On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
>>On Saturday 18 June 2005 15:22, Jon Smirl wrote:
>>>On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
>>>
The point to notice here is that these registers generally segmente
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tino Keitel wrote:
> I installed the r300 driver with X.org and Mesa CVS and it works
> without problems until now.
>
> However, one app called mythtv tries use OpenGL and brought this error:
>
> libGL: XF86DRIGetClientDriverName: 4.0.1 r300 (screen
On Monday 20 June 2005 00:03, Jon Smirl wrote:
> On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > Obviously determining which sets of registers can be mapped through the
> > drm is a card-by-card problem. Different cards have different register
> > maps, by definition. But the DRI drivers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adam Jackson wrote:
> On Friday 17 June 2005 23:18, Ian Romanick wrote:
>
>>Basically, user-mode should say to the kernel, "Please initialize
>>yourself with these tunable parameters." The kernel should then do
>>whatever it wants and let user-mode k
19 matches
Mail list logo
