* Re: R200 DRM/KMS
2015-07-06 21:26 ` Daniel Vetter
@ 2015-07-06 21:50 ` Steven Newbury
2015-07-07 6:18 ` Wayland and GLES1 (Re: R200 DRM/KMS) Pekka Paalanen
2015-07-07 13:22 ` R200 DRM/KMS Steven Newbury
2015-07-07 13:46 ` Steven Newbury
2 siblings, 1 reply; 28+ messages in thread
From: Steven Newbury @ 2015-07-06 21:50 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 3775 bytes --]
On Mon, 2015-07-06 at 23:26 +0200, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 09:06:28PM +0100, Steven Newbury wrote:
> > On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> > > On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury <
> > > steve@snewbury.org.uk
> > > > wrote:
> > > > On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> > > > > On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury <
> > > > > steve@snewbury.org.uk
> > > > > > wrote:
> > > > > > Hi,
> > > > > > I've been trying to get DRM/KMS working with the current
> > > > > > graphics
> > > > > > stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series
> > > > > > card. I
> > > > > > assumed this should be working since KMS was implemented
> > > > > > for
> > > > > > it a
> > > > > > while back, and it has been working with xf86-video-ati
> > > > > > -6.x.
> > > > > >
> > > > > > Unfortunately, it doesn't seem to work.
> > > > > >
> > > > > > I've narrowed it down to drmSetInterfaceVersion() failing
> > > > > > when
> > > > > > called
> > > > > > from the ATI driver (in radeon_kms.c). This is a bit
> > > > > > strange
> > > > > > since,
> > > > > > /sys/class/drm/version correctly reports 1.1.0 20060810.
> > > > > > Presuably
> > > > > > it's getting the correct fd for the DRM master otherwise
> > > > > > it
> > > > > > should
> > > > > > bail earlier?
> > > > > >
> > > > > >
> > > > > > Googling confirms others have had the same issue, and
> > > > > > generally the
> > > > > > resolution has been to stick with the old driver.
> > > > > >
> > > > > > Should this be working? Is it known to be broken?
> > > > >
> > > > > It should be working. Make sure the kernel driver has kms
> > > > > enabled,
> > > > > firmware available, and that the kernel driver is loaded
> > > > > before
> > > > > starting X. If the kernel driver is not loaded before X
> > > > > starts
> > > > > you
> > > > > can get a version mis-match error.
> > > >
> > > > Yes, using Gentoos 4.1.1 kernel, driver is definitely loaded,
> > > > with
> > > > modeset=1, which is working, all sysfs entries are there. gdm
> > > > manages
> > > > to fall back to starting up an X session without using DRM
> > > > swrast
> > > > -only, not something you want to experience on such a weak CPU!
> > > >
> > >
> > > If the kernel driver loads properly and you get a kms console you
> > > should be good to go.
> > >
> > > > Manually starting X fails with the "[drm] failed to set drm
> > > > interface
> > > > version." error.
> > > >
> > >
> > > Maybe the ddx with that old system was build without KMS support?
> > Everything is freshly compiled. The error itself is coming from
> > radeon_kms.c:651 in the ddx.
>
> Do you have latest libdrm? We might have accidentally broken this
> for very
> old versions of libdrm (although surprising this would compile with
> everything else).
> -Daniel
It's the latest in portage:
x11-libs/libdrm-2.4.62::gentoo USE="libkms -static-libs -valgrind"VIDEO_CARDS="radeon (-exynos) (-freedreno) -intel -nouveau (-omap) (-tegra) -vmware"
I'll know tomorrow whether downgrading works, if not, I'm suspecting it's a compiler bug. I have wondered though how much testing R200 could be getting with the latest stack.
If it is a mis-compile, I guess it must be either in libdrm or the ddx
- hopefully, at least that shouldn't mean too much compiling!
Slightly off topic, I'm curious whether R200 could be used with
Wayland. How difficult/possible would it be to get R200 working with
gles1? Obviously, gles2 would be a non-starter given it's OpenGL1.3
hardware. Would gles1 be sufficient to run a Wayland compositor, I'm
guessing probably not..?
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Wayland and GLES1 (Re: R200 DRM/KMS)
2015-07-06 21:50 ` Steven Newbury
@ 2015-07-07 6:18 ` Pekka Paalanen
2015-07-08 20:56 ` Steven Newbury
0 siblings, 1 reply; 28+ messages in thread
From: Pekka Paalanen @ 2015-07-07 6:18 UTC (permalink / raw)
To: Steven Newbury; +Cc: Maling list - DRI developers
On Mon, 06 Jul 2015 22:50:30 +0100
Steven Newbury <steve@snewbury.org.uk> wrote:
> Would gles1 be sufficient to run a Wayland compositor, I'm
> guessing probably not..?
If you can find a Wayland compositor that is written to composite with
GLES1, that's all you need from the "Wayland side". (Yeah, this has
nothing to do with Wayland per se.) Compositing in itself without any
effects is very simple, as long as you get the textures up.
Or, if you find a Wayland compositor written to use desktop OpenGL for
compositing and does not use features your GL driver does not expose,
that's good too.
Absolutely nothing about Wayland limits your choice of the GL flavour -
even more so as the compositor is not running *on* Wayland.
Also, the question of running GL apps on Wayland is a whole another
matter. There used to be a common misconception that Wayland had
something to do with only allowing GLES.
Finally, there is the option of software rendering for composition...
Thanks,
pq
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Wayland and GLES1 (Re: R200 DRM/KMS)
2015-07-07 6:18 ` Wayland and GLES1 (Re: R200 DRM/KMS) Pekka Paalanen
@ 2015-07-08 20:56 ` Steven Newbury
2015-07-08 21:01 ` Steven Newbury
0 siblings, 1 reply; 28+ messages in thread
From: Steven Newbury @ 2015-07-08 20:56 UTC (permalink / raw)
To: Pekka Paalanen; +Cc: Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 1309 bytes --]
On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> On Mon, 06 Jul 2015 22:50:30 +0100
> Steven Newbury <steve@snewbury.org.uk> wrote:
>
> > Would gles1 be sufficient to run a Wayland compositor, I'm
> > guessing probably not..?
>
> If you can find a Wayland compositor that is written to composite
> with
> GLES1, that's all you need from the "Wayland side". (Yeah, this has
> nothing to do with Wayland per se.) Compositing in itself without any
> effects is very simple, as long as you get the textures up.
>
> Or, if you find a Wayland compositor written to use desktop OpenGL
> for
> compositing and does not use features your GL driver does not expose,
> that's good too.
>
Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> Absolutely nothing about Wayland limits your choice of the GL
> flavour -
> even more so as the compositor is not running *on* Wayland.
>
> Also, the question of running GL apps on Wayland is a whole another
> matter. There used to be a common misconception that Wayland had
> something to do with only allowing GLES.
>
> Finally, there is the option of software rendering for composition...
>
Well, considering I was wondering about running Wayland on ancient
hardware, perhaps software compositing wouldn't be ideal! ;-)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Wayland and GLES1 (Re: R200 DRM/KMS)
2015-07-08 20:56 ` Steven Newbury
@ 2015-07-08 21:01 ` Steven Newbury
2015-07-09 2:32 ` Michel Dänzer
0 siblings, 1 reply; 28+ messages in thread
From: Steven Newbury @ 2015-07-08 21:01 UTC (permalink / raw)
To: Pekka Paalanen; +Cc: Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 1547 bytes --]
On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> > On Mon, 06 Jul 2015 22:50:30 +0100
> > Steven Newbury <steve@snewbury.org.uk> wrote:
> >
> > > Would gles1 be sufficient to run a Wayland compositor, I'm
> > > guessing probably not..?
> >
> > If you can find a Wayland compositor that is written to composite
> > with
> > GLES1, that's all you need from the "Wayland side". (Yeah, this has
> > nothing to do with Wayland per se.) Compositing in itself without
> > any
> > effects is very simple, as long as you get the textures up.
> >
> > Or, if you find a Wayland compositor written to use desktop OpenGL
> > for
> > compositing and does not use features your GL driver does not
> > expose,
> > that's good too.
> >
> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
>
To answer my own question, it seems that is possible. I wonder if it
works with mutter/cogl???
> > Absolutely nothing about Wayland limits your choice of the GL
> > flavour -
> > even more so as the compositor is not running *on* Wayland.
> >
> > Also, the question of running GL apps on Wayland is a whole another
> > matter. There used to be a common misconception that Wayland had
> > something to do with only allowing GLES.
> >
> > Finally, there is the option of software rendering for
> > composition...
> >
> Well, considering I was wondering about running Wayland on ancient
> hardware, perhaps software compositing wouldn't be ideal! ;-)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Wayland and GLES1 (Re: R200 DRM/KMS)
2015-07-08 21:01 ` Steven Newbury
@ 2015-07-09 2:32 ` Michel Dänzer
2015-07-09 6:58 ` Steven Newbury
0 siblings, 1 reply; 28+ messages in thread
From: Michel Dänzer @ 2015-07-09 2:32 UTC (permalink / raw)
To: Steven Newbury, Pekka Paalanen; +Cc: Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 1275 bytes --]
On 09.07.2015 06:01, Steven Newbury wrote:
> On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
>> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
>>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
>>> <steve@snewbury.org.uk> wrote:
>>>
>>>> Would gles1 be sufficient to run a Wayland compositor, I'm
>>>> guessing probably not..?
>>>
>>> If you can find a Wayland compositor that is written to composite
>>> with GLES1, that's all you need from the "Wayland side". (Yeah,
>>> this has nothing to do with Wayland per se.) Compositing in
>>> itself without any effects is very simple, as long as you get the
>>> textures up.
>>>
>>> Or, if you find a Wayland compositor written to use desktop
>>> OpenGL for compositing and does not use features your GL driver
>>> does not expose, that's good too.
>>>
>> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
>>
> To answer my own question, it seems that is possible. I wonder if
> it works with mutter/cogl???
It does.
However, your problem seems rather that gnome-shell/mutter doesn't
support R200 anymore.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 173 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Wayland and GLES1 (Re: R200 DRM/KMS)
2015-07-09 2:32 ` Michel Dänzer
@ 2015-07-09 6:58 ` Steven Newbury
2015-07-09 15:04 ` Alex Deucher
0 siblings, 1 reply; 28+ messages in thread
From: Steven Newbury @ 2015-07-09 6:58 UTC (permalink / raw)
To: michel; +Cc: dri-devel
On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> On 09.07.2015 06:01, Steven Newbury wrote:
> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> >>> <steve@snewbury.org.uk> wrote:
> >>>
> >>>> Would gles1 be sufficient to run a Wayland compositor, I'm
> >>>> guessing probably not..?
> >>>
> >>> If you can find a Wayland compositor that is written to composite
> >>> with GLES1, that's all you need from the "Wayland side". (Yeah,
> >>> this has nothing to do with Wayland per se.) Compositing in
> >>> itself without any effects is very simple, as long as you get the
> >>> textures up.
> >>>
> >>> Or, if you find a Wayland compositor written to use desktop
> >>> OpenGL for compositing and does not use features your GL driver
> >>> does not expose, that's good too.
> >>>
> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> >>
> > To answer my own question, it seems that is possible. I wonder if
> > it works with mutter/cogl???
>
> It does.
>
> However, your problem seems rather that gnome-shell/mutter doesn't
> support R200 anymore.
Yes, that's true. I wonder if I can revert the incompatible change or better create a env variable to revert to the compatible behaviour or something? I'll need to take a look...
[I'm going to be posting a lot from my phone, my laptop power jack has just broken, again! :-( You'd think after 3.5 decades of making laptops we'd have come up with a better design!]
--
Sent from my Jolla
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Wayland and GLES1 (Re: R200 DRM/KMS)
2015-07-09 6:58 ` Steven Newbury
@ 2015-07-09 15:04 ` Alex Deucher
2015-07-09 16:02 ` Steven Newbury
0 siblings, 1 reply; 28+ messages in thread
From: Alex Deucher @ 2015-07-09 15:04 UTC (permalink / raw)
To: Steven Newbury; +Cc: Michel Dänzer, Maling list - DRI developers
On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>
>
> On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
>> On 09.07.2015 06:01, Steven Newbury wrote:
>> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
>> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
>> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
>> >>> <steve@snewbury.org.uk> wrote:
>> >>>
>> >>>> Would gles1 be sufficient to run a Wayland compositor, I'm
>> >>>> guessing probably not..?
>> >>>
>> >>> If you can find a Wayland compositor that is written to composite
>> >>> with GLES1, that's all you need from the "Wayland side". (Yeah,
>> >>> this has nothing to do with Wayland per se.) Compositing in
>> >>> itself without any effects is very simple, as long as you get the
>> >>> textures up.
>> >>>
>> >>> Or, if you find a Wayland compositor written to use desktop
>> >>> OpenGL for compositing and does not use features your GL driver
>> >>> does not expose, that's good too.
>> >>>
>> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
>> >>
>> > To answer my own question, it seems that is possible. I wonder if
>> > it works with mutter/cogl???
>>
>> It does.
>>
>> However, your problem seems rather that gnome-shell/mutter doesn't
>> support R200 anymore.
> Yes, that's true. I wonder if I can revert the incompatible change or better create a env variable to revert to the compatible behaviour or something? I'll need to take a look...
I'm not sure how valid this is any more:
https://bugs.freedesktop.org/show_bug.cgi?id=51658
Basic issue is that r1xx/r2xx hw only has a limited number of render
buffer formats while they support a lot of texture formats. Gnome
shell expects to be able to render to the same formats they can
texture from.
Alex
>
> [I'm going to be posting a lot from my phone, my laptop power jack has just broken, again! :-( You'd think after 3.5 decades of making laptops we'd have come up with a better design!]
> --
> Sent from my Jolla
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Wayland and GLES1 (Re: R200 DRM/KMS)
2015-07-09 15:04 ` Alex Deucher
@ 2015-07-09 16:02 ` Steven Newbury
2015-07-10 13:41 ` Steven Newbury
2015-07-10 13:41 ` Steven Newbury
0 siblings, 2 replies; 28+ messages in thread
From: Steven Newbury @ 2015-07-09 16:02 UTC (permalink / raw)
To: alexdeucher; +Cc: michel, dri-devel
On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote:
> On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> >
> >
> > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> >> On 09.07.2015 06:01, Steven Newbury wrote:
> >> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> >> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> >> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> >> >>> <steve@snewbury.org.uk> wrote:
> >> >>>
> >> >>>> Would gles1 be sufficient to run a Wayland compositor, I'm
> >> >>>> guessing probably not..?
> >> >>>
> >> >>> If you can find a Wayland compositor that is written to composite
> >> >>> with GLES1, that's all you need from the "Wayland side". (Yeah,
> >> >>> this has nothing to do with Wayland per se.) Compositing in
> >> >>> itself without any effects is very simple, as long as you get the
> >> >>> textures up.
> >> >>>
> >> >>> Or, if you find a Wayland compositor written to use desktop
> >> >>> OpenGL for compositing and does not use features your GL driver
> >> >>> does not expose, that's good too.
> >> >>>
> >> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> >> >>
> >> > To answer my own question, it seems that is possible. I wonder if
> >> > it works with mutter/cogl???
> >>
> >> It does.
> >>
> >> However, your problem seems rather that gnome-shell/mutter doesn't
> >> support R200 anymore.
> > Yes, that's true. I wonder if I can revert the incompatible change or better create a env variable to revert to the compatible behaviour or something? I'll need to take a look...
>
> I'm not sure how valid this is any more:
> https://bugs.freedesktop.org/show_bug.cgi?id=51658
>
> Basic issue is that r1xx/r2xx hw only has a limited number of render
> buffer formats while they support a lot of texture formats. Gnome
> shell expects to be able to render to the same formats they can
> texture from.
>
It looks like a bit of a hack, it's a pity to lose valid texture formats, but I've applied the patches from the bug after a little manual intervention. It's building now, will take some time!
--
Sent from my Jolla
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Wayland and GLES1 (Re: R200 DRM/KMS)
2015-07-09 16:02 ` Steven Newbury
@ 2015-07-10 13:41 ` Steven Newbury
2015-07-10 13:41 ` Steven Newbury
1 sibling, 0 replies; 28+ messages in thread
From: Steven Newbury @ 2015-07-10 13:41 UTC (permalink / raw)
To: steve; +Cc: michel, dri-devel
On Thu Jul 9 17:02:12 2015 GMT+0100, Steven Newbury wrote:
> On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote:
> > On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> > >
> > >
> > > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> > >> On 09.07.2015 06:01, Steven Newbury wrote:
> > >> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> > >> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> > >> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> > >> >>> <steve@snewbury.org.uk> wrote:
> > >> >>>
> > >> >>>> Would gles1 be sufficient to run a Wayland compositor, I'm
> > >> >>>> guessing probably not..?
> > >> >>>
> > >> >>> If you can find a Wayland compositor that is written to composite
> > >> >>> with GLES1, that's all you need from the "Wayland side". (Yeah,
> > >> >>> this has nothing to do with Wayland per se.) Compositing in
> > >> >>> itself without any effects is very simple, as long as you get the
> > >> >>> textures up.
> > >> >>>
> > >> >>> Or, if you find a Wayland compositor written to use desktop
> > >> >>> OpenGL for compositing and does not use features your GL driver
> > >> >>> does not expose, that's good too.
> > >> >>>
> > >> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> > >> >>
> > >> > To answer my own question, it seems that is possible. I wonder if
> > >> > it works with mutter/cogl???
> > >>
> > >> It does.
> > >>
> > >> However, your problem seems rather that gnome-shell/mutter doesn't
> > >> support R200 anymore.
> > > Yes, that's true. I wonder if I can revert the incompatible change or better create a env variable to revert to the compatible behaviour or something? I'll need to take a look...
> >
> > I'm not sure how valid this is any more:
> > https://bugs.freedesktop.org/show_bug.cgi?id=51658
> >
> > Basic issue is that r1xx/r2xx hw only has a limited number of render
> > buffer formats while they support a lot of texture formats. Gnome
> > shell expects to be able to render to the same formats they can
> > texture from.
> >
> It looks like a bit of a hack, it's a pity to lose valid texture formats, but I've applied the patches from the bug after a little manual intervention. It's building now, will take some time!
Didn't work. Still get the same error! :-(
On the other hand, I've got muffin to work compositor is actually okay, so thought I'd try cinnamon, but it's trying to use 1.5GB which isn't going to work! ;-)
Will probably revert to Xfce...
--
Sent from my Jolla
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Wayland and GLES1 (Re: R200 DRM/KMS)
2015-07-09 16:02 ` Steven Newbury
2015-07-10 13:41 ` Steven Newbury
@ 2015-07-10 13:41 ` Steven Newbury
1 sibling, 0 replies; 28+ messages in thread
From: Steven Newbury @ 2015-07-10 13:41 UTC (permalink / raw)
To: steve; +Cc: michel, dri-devel
On Thu Jul 9 17:02:12 2015 GMT+0100, Steven Newbury wrote:
> On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote:
> > On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> > >
> > >
> > > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> > >> On 09.07.2015 06:01, Steven Newbury wrote:
> > >> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> > >> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> > >> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> > >> >>> <steve@snewbury.org.uk> wrote:
> > >> >>>
> > >> >>>> Would gles1 be sufficient to run a Wayland compositor, I'm
> > >> >>>> guessing probably not..?
> > >> >>>
> > >> >>> If you can find a Wayland compositor that is written to composite
> > >> >>> with GLES1, that's all you need from the "Wayland side". (Yeah,
> > >> >>> this has nothing to do with Wayland per se.) Compositing in
> > >> >>> itself without any effects is very simple, as long as you get the
> > >> >>> textures up.
> > >> >>>
> > >> >>> Or, if you find a Wayland compositor written to use desktop
> > >> >>> OpenGL for compositing and does not use features your GL driver
> > >> >>> does not expose, that's good too.
> > >> >>>
> > >> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> > >> >>
> > >> > To answer my own question, it seems that is possible. I wonder if
> > >> > it works with mutter/cogl???
> > >>
> > >> It does.
> > >>
> > >> However, your problem seems rather that gnome-shell/mutter doesn't
> > >> support R200 anymore.
> > > Yes, that's true. I wonder if I can revert the incompatible change or better create a env variable to revert to the compatible behaviour or something? I'll need to take a look...
> >
> > I'm not sure how valid this is any more:
> > https://bugs.freedesktop.org/show_bug.cgi?id=51658
> >
> > Basic issue is that r1xx/r2xx hw only has a limited number of render
> > buffer formats while they support a lot of texture formats. Gnome
> > shell expects to be able to render to the same formats they can
> > texture from.
> >
> It looks like a bit of a hack, it's a pity to lose valid texture formats, but I've applied the patches from the bug after a little manual intervention. It's building now, will take some time!
Didn't work. Still get the same error! :-(
On the other hand, I've got muffin to work compositor is actually okay, so thought I'd try cinnamon, but it's trying to use 1.5GB which isn't going to work! ;-)
Will probably revert to Xfce...
--
Sent from my Jolla
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: R200 DRM/KMS
2015-07-06 21:26 ` Daniel Vetter
2015-07-06 21:50 ` Steven Newbury
@ 2015-07-07 13:22 ` Steven Newbury
2015-07-07 13:46 ` Steven Newbury
2 siblings, 0 replies; 28+ messages in thread
From: Steven Newbury @ 2015-07-07 13:22 UTC (permalink / raw)
To: daniel; +Cc: dri-devel
On Mon Jul 6 22:26:25 2015 GMT+0100, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 09:06:28PM +0100, Steven Newbury wrote:
> > On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> > > On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury <steve@snewbury.org.uk
> > > > wrote:
> > > > On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> > > > > On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury <
> > > > > steve@snewbury.org.uk
> > > > > > wrote:
> > > > > > Hi,
> > > > > > I've been trying to get DRM/KMS working with the current
> > > > > > graphics
> > > > > > stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series
> > > > > > card. I
> > > > > > assumed this should be working since KMS was implemented for
> > > > > > it a
> > > > > > while back, and it has been working with xf86-video-ati-6.x.
> > > > > >
> > > > > > Unfortunately, it doesn't seem to work.
> > > > > >
> > > > > > I've narrowed it down to drmSetInterfaceVersion() failing when
> > > > > > called
> > > > > > from the ATI driver (in radeon_kms.c). This is a bit strange
> > > > > > since,
> > > > > > /sys/class/drm/version correctly reports 1.1.0 20060810.
> > > > > > Presuably
> > > > > > it's getting the correct fd for the DRM master otherwise it
> > > > > > should
> > > > > > bail earlier?
> > > > > >
> > > > > >
> > > > > > Googling confirms others have had the same issue, and
> > > > > > generally the
> > > > > > resolution has been to stick with the old driver.
> > > > > >
> > > > > > Should this be working? Is it known to be broken?
> > > > >
> > > > > It should be working. Make sure the kernel driver has kms
> > > > > enabled,
> > > > > firmware available, and that the kernel driver is loaded before
> > > > > starting X. If the kernel driver is not loaded before X starts
> > > > > you
> > > > > can get a version mis-match error.
> > > >
> > > > Yes, using Gentoos 4.1.1 kernel, driver is definitely loaded, with
> > > > modeset=1, which is working, all sysfs entries are there. gdm
> > > > manages
> > > > to fall back to starting up an X session without using DRM swrast
> > > > -only, not something you want to experience on such a weak CPU!
> > > >
> > >
> > > If the kernel driver loads properly and you get a kms console you
> > > should be good to go.
> > >
> > > > Manually starting X fails with the "[drm] failed to set drm
> > > > interface
> > > > version." error.
> > > >
> > >
> > > Maybe the ddx with that old system was build without KMS support?
> > Everything is freshly compiled. The error itself is coming from
> > radeon_kms.c:651 in the ddx.
>
> Do you have latest libdrm? We might have accidentally broken this for very
> old versions of libdrm (although surprising this would compile with
> everything else).
> -Daniel
> >
> > >
> > > Alex
> > >
> > > > It's a very old system, PCI-only(!) Coppermine-128, belonging to a
> > > > friend. The system previously was (very slowly) running Ubuntu 10
> > > > LTS, I think. It's not my machine so I'm not able to have
> > > > continuous
> > > > access, but R200 DRM/KMS was working. Apparently, Ubuntu no longer
> > > > support R200, so no further updates were possible.
> > > >
> > > > My friend can't afford a new machine at the moment; and since I'm a
> > > > long time Gentoo dev I took it upon myself to build him a optimized
> > > > desktop with gcc-5, where possible LTO, -Os, -march=pentium3 with
> > > > the
> > > > system L1 and L2 cache size information. It's quite possible some
> > > > part of the gfx stack is miscompiled, I tested it pretty throughly
> > > > under qemu (with qxl) before deployment, but that of course didn't
> > > > exercise the R200 driver. FWIW, other than the failing DRI,
> > > > performance is surprisingly OK, not super fast obviously, but a
> > > > *lot*
> > > > better than under Ubuntu! (start-up time is alot quicker, by an
> > > > order
> > > > of magnitude!)
> > > >
> > > > I'm attempting to downgrade the xserver and drivers (on the live
> > > > system) to see if that works, you can imagine that takes a little
> > > > while on a Coppermine-128! I'll find out tomorrow. Otherwise, I
> > > > guess I'm recompiling the stack with gcc-4.9 and no-LTO...
>
>
>
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
--
Sent from my Jolla
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: R200 DRM/KMS
2015-07-06 21:26 ` Daniel Vetter
2015-07-06 21:50 ` Steven Newbury
2015-07-07 13:22 ` R200 DRM/KMS Steven Newbury
@ 2015-07-07 13:46 ` Steven Newbury
2015-07-07 14:12 ` Alex Deucher
2 siblings, 1 reply; 28+ messages in thread
From: Steven Newbury @ 2015-07-07 13:46 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 5041 bytes --]
On Mon, 2015-07-06 at 23:26 +0200, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 09:06:28PM +0100, Steven Newbury wrote:
> > On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> > > On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury <
> > > steve@snewbury.org.uk
> > > > wrote:
> > > > On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> > > > > On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury <
> > > > > steve@snewbury.org.uk
> > > > > > wrote:
> > > > > > Hi,
> > > > > > I've been trying to get DRM/KMS working with the current
> > > > > > graphics
> > > > > > stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series
> > > > > > card. I
> > > > > > assumed this should be working since KMS was implemented
> > > > > > for
> > > > > > it a
> > > > > > while back, and it has been working with xf86-video-ati
> > > > > > -6.x.
> > > > > >
> > > > > > Unfortunately, it doesn't seem to work.
> > > > > >
> > > > > > I've narrowed it down to drmSetInterfaceVersion() failing
> > > > > > when
> > > > > > called
> > > > > > from the ATI driver (in radeon_kms.c). This is a bit
> > > > > > strange
> > > > > > since,
> > > > > > /sys/class/drm/version correctly reports 1.1.0 20060810.
> > > > > > Presuably
> > > > > > it's getting the correct fd for the DRM master otherwise
> > > > > > it
> > > > > > should
> > > > > > bail earlier?
> > > > > >
> > > > > >
> > > > > > Googling confirms others have had the same issue, and
> > > > > > generally the
> > > > > > resolution has been to stick with the old driver.
> > > > > >
> > > > > > Should this be working? Is it known to be broken?
> > > > >
> > > > > It should be working. Make sure the kernel driver has kms
> > > > > enabled,
> > > > > firmware available, and that the kernel driver is loaded
> > > > > before
> > > > > starting X. If the kernel driver is not loaded before X
> > > > > starts
> > > > > you
> > > > > can get a version mis-match error.
> > > >
> > > > Yes, using Gentoos 4.1.1 kernel, driver is definitely loaded,
> > > > with
> > > > modeset=1, which is working, all sysfs entries are there. gdm
> > > > manages
> > > > to fall back to starting up an X session without using DRM
> > > > swrast
> > > > -only, not something you want to experience on such a weak CPU!
> > > >
> > >
> > > If the kernel driver loads properly and you get a kms console you
> > > should be good to go.
> > >
> > > > Manually starting X fails with the "[drm] failed to set drm
> > > > interface
> > > > version." error.
> > > >
> > >
> > > Maybe the ddx with that old system was build without KMS support?
> > Everything is freshly compiled. The error itself is coming from
> > radeon_kms.c:651 in the ddx.
>
> Do you have latest libdrm? We might have accidentally broken this
> for very
> old versions of libdrm (although surprising this would compile with
> everything else).
> -Daniel
> >
> > >
> > > Alex
> > >
> > > > It's a very old system, PCI-only(!) Coppermine-128, belonging
> > > > to a
> > > > friend. The system previously was (very slowly) running
> > > > Ubuntu 10
> > > > LTS, I think. It's not my machine so I'm not able to have
> > > > continuous
> > > > access, but R200 DRM/KMS was working. Apparently, Ubuntu no
> > > > longer
> > > > support R200, so no further updates were possible.
> > > >
> > > > My friend can't afford a new machine at the moment; and since
> > > > I'm a
> > > > long time Gentoo dev I took it upon myself to build him a
> > > > optimized
> > > > desktop with gcc-5, where possible LTO, -Os, -march=pentium3
> > > > with
> > > > the
> > > > system L1 and L2 cache size information. It's quite possible
> > > > some
> > > > part of the gfx stack is miscompiled, I tested it pretty
> > > > throughly
> > > > under qemu (with qxl) before deployment, but that of course
> > > > didn't
> > > > exercise the R200 driver. FWIW, other than the failing DRI,
> > > > performance is surprisingly OK, not super fast obviously, but
> > > > a
> > > > *lot*
> > > > better than under Ubuntu! (start-up time is alot quicker, by
> > > > an
> > > > order
> > > > of magnitude!)
> > > >
> > > > I'm attempting to downgrade the xserver and drivers (on the
> > > > live
> > > > system) to see if that works, you can imagine that takes a
> > > > little
> > > > while on a Coppermine-128! I'll find out tomorrow.
> > > > Otherwise, I
> > > > guess I'm recompiling the stack with gcc-4.9 and no-LTO...
>
Sorry about the accidental e-mail.
I've tried an xserver-1.16, and ddx, libdrm without LTO and with
gcc4.9. Exactly the same thing. I wondered whether the unused i810
could be interfering but triggering a device "remove" before starting
X made no difference.
I'm a bit of a loss. I suppose I could try writing a simple test for
drmSetInterfaceVersion(). At least that should determine whether the
xserver/ddx is in the clear.
Any other ideas?
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: R200 DRM/KMS
2015-07-07 13:46 ` Steven Newbury
@ 2015-07-07 14:12 ` Alex Deucher
2015-07-07 15:44 ` Steven Newbury
2015-07-08 12:58 ` Steven Newbury
0 siblings, 2 replies; 28+ messages in thread
From: Alex Deucher @ 2015-07-07 14:12 UTC (permalink / raw)
To: Steven Newbury; +Cc: Maling list - DRI developers
On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>
> I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> gcc4.9. Exactly the same thing. I wondered whether the unused i810
> could be interfering but triggering a device "remove" before starting
> X made no difference.
>
> I'm a bit of a loss. I suppose I could try writing a simple test for
> drmSetInterfaceVersion(). At least that should determine whether the
> xserver/ddx is in the clear.
>
> Any other ideas?
>
Can you start a non-X runlevel and start X manually as root (assuming
you are using a login manager now)?
Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: R200 DRM/KMS
2015-07-07 14:12 ` Alex Deucher
@ 2015-07-07 15:44 ` Steven Newbury
2015-07-08 12:58 ` Steven Newbury
1 sibling, 0 replies; 28+ messages in thread
From: Steven Newbury @ 2015-07-07 15:44 UTC (permalink / raw)
To: Alex Deucher; +Cc: Maling list - DRI developers
[-- Attachment #1.1.1: Type: text/plain, Size: 876 bytes --]
On Tue, 2015-07-07 at 10:12 -0400, Alex Deucher wrote:
> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <steve@snewbury.org.uk
> > wrote:
> >
> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> > gcc4.9. Exactly the same thing. I wondered whether the unused
> > i810
> > could be interfering but triggering a device "remove" before
> > starting
> > X made no difference.
> >
> > I'm a bit of a loss. I suppose I could try writing a simple test
> > for
> > drmSetInterfaceVersion(). At least that should determine whether
> > the
> > xserver/ddx is in the clear.
> >
> > Any other ideas?
> >
>
> Can you start a non-X runlevel and start X manually as root (assuming
> you are using a login manager now)?
I've written a simple test based on the code from radeon_kms.c
I just need to try it on the actual hw now... :-)
[-- Attachment #1.1.2: test-drm.c --]
[-- Type: text/x-csrc, Size: 735 bytes --]
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <xf86drm.h>
int main()
{
drmSetVersion sv;
int dir_fd, drm_fd, err;
char *drm_directory = "/dev/dri/";
char *node = "card0";
dir_fd = open(drm_directory, O_RDONLY);
if (dir_fd < 0) {
printf("Directory open failed!\n");
return -1;
}
drm_fd = openat(dir_fd, node, O_RDWR);
if (dir_fd < 0) {
printf("File open failed!\n");
return -1;
}
sv.drm_di_major = 1;
sv.drm_di_minor = 1;
sv.drm_dd_major = -1;
sv.drm_dd_minor = -1;
err = drmSetInterfaceVersion(drm_fd, &sv);
if (err != 0) {
printf("FAILED (%d)\n", err);
return -1;
}
printf("SUCCESS\n");
return 0;
}
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: R200 DRM/KMS
2015-07-07 14:12 ` Alex Deucher
2015-07-07 15:44 ` Steven Newbury
@ 2015-07-08 12:58 ` Steven Newbury
2015-07-08 13:20 ` Alex Deucher
1 sibling, 1 reply; 28+ messages in thread
From: Steven Newbury @ 2015-07-08 12:58 UTC (permalink / raw)
To: alexdeucher; +Cc: dri-devel
On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> >
> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> > gcc4.9. Exactly the same thing. I wondered whether the unused i810
> > could be interfering but triggering a device "remove" before starting
> > X made no difference.
> >
> > I'm a bit of a loss. I suppose I could try writing a simple test for
> > drmSetInterfaceVersion(). At least that should determine whether the
> > xserver/ddx is in the clear.
> >
> > Any other ideas?
> >
>
> Can you start a non-X runlevel and start X manually as root (assuming
> you are using a login manager now)?
>
My test program worked fine. I considerably improved it over the version I posted. I'll send it to the list when I get back.
I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much further. Starting Xserver as root apparently started normally, according to the log, although there was a permission denied error on mode set during init. I don't know whether it was related or not, but the display then hung with a non-blinking cursor. Strange to get a permission denied as root!
Starting GNOME via gdm gives a working slow X session but for some reason only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. Perhaps it's a config error somewhere.. ?
startx as a regular user just works!
But mutter doesn't, perhaps that's
why a gnome session isn't working. It just gives the following error:
Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
Mutter is supposed to work on r200, right?
--
Sent from my Jolla
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: R200 DRM/KMS
2015-07-08 12:58 ` Steven Newbury
@ 2015-07-08 13:20 ` Alex Deucher
2015-07-08 13:53 ` Steven Newbury
0 siblings, 1 reply; 28+ messages in thread
From: Alex Deucher @ 2015-07-08 13:20 UTC (permalink / raw)
To: Steven Newbury; +Cc: Maling list - DRI developers
On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>
>
> On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
>> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>> >
>> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
>> > gcc4.9. Exactly the same thing. I wondered whether the unused i810
>> > could be interfering but triggering a device "remove" before starting
>> > X made no difference.
>> >
>> > I'm a bit of a loss. I suppose I could try writing a simple test for
>> > drmSetInterfaceVersion(). At least that should determine whether the
>> > xserver/ddx is in the clear.
>> >
>> > Any other ideas?
>> >
>>
>> Can you start a non-X runlevel and start X manually as root (assuming
>> you are using a login manager now)?
>>
> My test program worked fine. I considerably improved it over the version I posted. I'll send it to the list when I get back.
>
> I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much further. Starting Xserver as root apparently started normally, according to the log, although there was a permission denied error on mode set during init. I don't know whether it was related or not, but the display then hung with a non-blinking cursor. Strange to get a permission denied as root!
>
> Starting GNOME via gdm gives a working slow X session but for some reason only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. Perhaps it's a config error somewhere.. ?
>
> startx as a regular user just works!
>
> But mutter doesn't, perhaps that's
> why a gnome session isn't working. It just gives the following error:
> Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
>
> Mutter is supposed to work on r200, right?
IIRC it tries to use a render buffer format that's not supported by the hw.
Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: R200 DRM/KMS
2015-07-08 13:20 ` Alex Deucher
@ 2015-07-08 13:53 ` Steven Newbury
2015-07-08 13:55 ` Alex Deucher
0 siblings, 1 reply; 28+ messages in thread
From: Steven Newbury @ 2015-07-08 13:53 UTC (permalink / raw)
To: alexdeucher; +Cc: dri-devel
On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
> On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> >
> >
> > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
> >> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> >> >
> >> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> >> > gcc4.9. Exactly the same thing. I wondered whether the unused i810
> >> > could be interfering but triggering a device "remove" before starting
> >> > X made no difference.
> >> >
> >> > I'm a bit of a loss. I suppose I could try writing a simple test for
> >> > drmSetInterfaceVersion(). At least that should determine whether the
> >> > xserver/ddx is in the clear.
> >> >
> >> > Any other ideas?
> >> >
> >>
> >> Can you start a non-X runlevel and start X manually as root (assuming
> >> you are using a login manager now)?
> >>
> > My test program worked fine. I considerably improved it over the version I posted. I'll send it to the list when I get back.
> >
> > I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much further. Starting Xserver as root apparently started normally, according to the log, although there was a permission denied error on mode set during init. I don't know whether it was related or not, but the display then hung with a non-blinking cursor. Strange to get a permission denied as root!
> >
> > Starting GNOME via gdm gives a working slow X session but for some reason only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. Perhaps it's a config error somewhere.. ?
> >
> > startx as a regular user just works!
> >
> > But mutter doesn't, perhaps that's
> > why a gnome session isn't working. It just gives the following error:
> > Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
> >
> > Mutter is supposed to work on r200, right?
>
> IIRC it tries to use a render buffer format that's not supported by the hw.
Is there anything to be done about it? Have to use a different wm/compositor?
Any idea why removing the call from radeon_kms.c worked?
--
Sent from my Jolla
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: R200 DRM/KMS
2015-07-08 13:53 ` Steven Newbury
@ 2015-07-08 13:55 ` Alex Deucher
2015-07-08 16:10 ` Emil Velikov
0 siblings, 1 reply; 28+ messages in thread
From: Alex Deucher @ 2015-07-08 13:55 UTC (permalink / raw)
To: Steven Newbury; +Cc: Maling list - DRI developers
On Wed, Jul 8, 2015 at 9:53 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>
>
> On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
>> On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>> >
>> >
>> > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
>> >> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>> >> >
>> >> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
>> >> > gcc4.9. Exactly the same thing. I wondered whether the unused i810
>> >> > could be interfering but triggering a device "remove" before starting
>> >> > X made no difference.
>> >> >
>> >> > I'm a bit of a loss. I suppose I could try writing a simple test for
>> >> > drmSetInterfaceVersion(). At least that should determine whether the
>> >> > xserver/ddx is in the clear.
>> >> >
>> >> > Any other ideas?
>> >> >
>> >>
>> >> Can you start a non-X runlevel and start X manually as root (assuming
>> >> you are using a login manager now)?
>> >>
>> > My test program worked fine. I considerably improved it over the version I posted. I'll send it to the list when I get back.
>> >
>> > I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much further. Starting Xserver as root apparently started normally, according to the log, although there was a permission denied error on mode set during init. I don't know whether it was related or not, but the display then hung with a non-blinking cursor. Strange to get a permission denied as root!
>> >
>> > Starting GNOME via gdm gives a working slow X session but for some reason only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. Perhaps it's a config error somewhere.. ?
>> >
>> > startx as a regular user just works!
>> >
>> > But mutter doesn't, perhaps that's
>> > why a gnome session isn't working. It just gives the following error:
>> > Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
>> >
>> > Mutter is supposed to work on r200, right?
>>
>> IIRC it tries to use a render buffer format that's not supported by the hw.
> Is there anything to be done about it? Have to use a different wm/compositor?
>
Another wm or compositor may help.
> Any idea why removing the call from radeon_kms.c worked?
No idea.
Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: R200 DRM/KMS
2015-07-08 13:55 ` Alex Deucher
@ 2015-07-08 16:10 ` Emil Velikov
2015-07-08 16:48 ` Steven Newbury
0 siblings, 1 reply; 28+ messages in thread
From: Emil Velikov @ 2015-07-08 16:10 UTC (permalink / raw)
To: Alex Deucher; +Cc: Maling list - DRI developers, Steven Newbury
On 8 July 2015 at 14:55, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Wed, Jul 8, 2015 at 9:53 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>>
>>
>> On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
>>> On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>>> >
>>> >
>>> > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
>>> >> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>>> >> >
>>> >> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
>>> >> > gcc4.9. Exactly the same thing. I wondered whether the unused i810
>>> >> > could be interfering but triggering a device "remove" before starting
>>> >> > X made no difference.
>>> >> >
>>> >> > I'm a bit of a loss. I suppose I could try writing a simple test for
>>> >> > drmSetInterfaceVersion(). At least that should determine whether the
>>> >> > xserver/ddx is in the clear.
>>> >> >
>>> >> > Any other ideas?
>>> >> >
>>> >>
>>> >> Can you start a non-X runlevel and start X manually as root (assuming
>>> >> you are using a login manager now)?
>>> >>
>>> > My test program worked fine. I considerably improved it over the version I posted. I'll send it to the list when I get back.
>>> >
>>> > I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much further. Starting Xserver as root apparently started normally, according to the log, although there was a permission denied error on mode set during init. I don't know whether it was related or not, but the display then hung with a non-blinking cursor. Strange to get a permission denied as root!
>>> >
>>> > Starting GNOME via gdm gives a working slow X session but for some reason only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. Perhaps it's a config error somewhere.. ?
>>> >
>>> > startx as a regular user just works!
>>> >
>>> > But mutter doesn't, perhaps that's
>>> > why a gnome session isn't working. It just gives the following error:
>>> > Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
>>> >
>>> > Mutter is supposed to work on r200, right?
>>>
>>> IIRC it tries to use a render buffer format that's not supported by the hw.
>> Is there anything to be done about it? Have to use a different wm/compositor?
>>
>
> Another wm or compositor may help.
>
>> Any idea why removing the call from radeon_kms.c worked?
>
> No idea.
>
From a quick look at the actual implementation drmSetInterfaceVersion
is not something that we want/need to use with KMS drivers.
In general the original issue sound like the drm driver is not (fully)
loaded before the xserver/ddx kicks in. Additionally it may be a race
condition if something else (plymouth) is using the device. In the
latter case DRM_MASTER might still be held by $(other_app), thus
attempting to either SetInterfaceVersion or do any modeset operation
will fail.
Personally I would add a healthy amount of printk/printf though the
kernel drm + radeon and the ddx.
Cheers
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: R200 DRM/KMS
2015-07-08 16:10 ` Emil Velikov
@ 2015-07-08 16:48 ` Steven Newbury
2015-07-08 22:44 ` Emil Velikov
0 siblings, 1 reply; 28+ messages in thread
From: Steven Newbury @ 2015-07-08 16:48 UTC (permalink / raw)
To: Emil Velikov; +Cc: Maling list - DRI developers
[-- Attachment #1.1.1: Type: text/plain, Size: 4177 bytes --]
On Wed, 2015-07-08 at 17:10 +0100, Emil Velikov wrote:
> On 8 July 2015 at 14:55, Alex Deucher <alexdeucher@gmail.com> wrote:
> > On Wed, Jul 8, 2015 at 9:53 AM, Steven Newbury <
> > steve@snewbury.org.uk> wrote:
> > >
> > >
> > > On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
> > > > On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury <
> > > > steve@snewbury.org.uk> wrote:
> > > > >
> > > > >
> > > > > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
> > > > > > On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <
> > > > > > steve@snewbury.org.uk> wrote:
> > > > > > >
> > > > > > > I've tried an xserver-1.16, and ddx, libdrm without LTO
> > > > > > > and with
> > > > > > > gcc4.9. Exactly the same thing. I wondered whether the
> > > > > > > unused i810
> > > > > > > could be interfering but triggering a device "remove"
> > > > > > > before starting
> > > > > > > X made no difference.
> > > > > > >
> > > > > > > I'm a bit of a loss. I suppose I could try writing a
> > > > > > > simple test for
> > > > > > > drmSetInterfaceVersion(). At least that should
> > > > > > > determine whether the
> > > > > > > xserver/ddx is in the clear.
> > > > > > >
> > > > > > > Any other ideas?
> > > > > > >
> > > > > >
> > > > > > Can you start a non-X runlevel and start X manually as
> > > > > > root (assuming
> > > > > > you are using a login manager now)?
> > > > > >
> > > > > My test program worked fine. I considerably improved it over
> > > > > the version I posted. I'll send it to the list when I get
> > > > > back.
> > > > >
> > > > > I removed the drmSetInterfaceVersion() from radeon_kms.c and
> > > > > it got much further. Starting Xserver as root apparently
> > > > > started normally, according to the log, although there was
> > > > > a permission denied error on mode set during init. I don't
> > > > > know whether it was related or not, but the display then
> > > > > hung with a non-blinking cursor. Strange to get a permission
> > > > > denied as root!
> > > > >
> > > > > Starting GNOME via gdm gives a working slow X session but
> > > > > for some reason only uses sw dri even though the Xorg log
> > > > > shows r200 DRI2 as initialized. Perhaps it's a config error
> > > > > somewhere.. ?
> > > > >
> > > > > startx as a regular user just works!
> > > > >
> > > > > But mutter doesn't, perhaps that's
> > > > > why a gnome session isn't working. It just gives the
> > > > > following error:
> > > > > Cogl-ERROR **: Failed to create texture 2d due to
> > > > > size/format constraints
> > > > >
> > > > > Mutter is supposed to work on r200, right?
> > > >
> > > > IIRC it tries to use a render buffer format that's not
> > > > supported by the hw.
> > > Is there anything to be done about it? Have to use a different
> > > wm/compositor?
> > >
> >
> > Another wm or compositor may help.
> >
> > > Any idea why removing the call from radeon_kms.c worked?
> >
> > No idea.
> >
> From a quick look at the actual implementation drmSetInterfaceVersion
> is not something that we want/need to use with KMS drivers.
>
> In general the original issue sound like the drm driver is not
> (fully)
> loaded before the xserver/ddx kicks in. Additionally it may be a race
> condition if something else (plymouth) is using the device. In the
> latter case DRM_MASTER might still be held by $(other_app), thus
> attempting to either SetInterfaceVersion or do any modeset operation
> will fail.
>
>
Sitting on a KMS console, "systemctl start gdm", no plymouth
installed. It's just during Xserver initialisation that
drmSetInterfaceVersion() fails. AFAIK Xserver startup is entirely
single process, single thread. I've written a little test utility
which works fine on the system in question.
Compile attached file with:
gcc -O2 -o test-drm test-drm.c $(pkg-config --cflags libdrm) $(pkg
-config --libs libdrm)
> Personally I would add a healthy amount of printk/printf though the
> kernel drm + radeon and the ddx.
I guess it doesn't really matter since patching out the code "fixes"
it...
[-- Attachment #1.1.2: test-drm.c --]
[-- Type: text/x-csrc, Size: 1783 bytes --]
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <xf86drm.h>
#include <string.h>
#include <limits.h>
#include <libgen.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
drmSetVersion sv;
drmVersion *gv;
int dir_fd, drm_fd, err, drm_major, drm_minor;
char *drm_directory = "/dev/dri/";
char *node = "card0";
if (argc > 2) {
printf ("Too many arguments!\n");
printf ("Usage: %s [DRM device node]\n", argv[0]);
return 1;
}
if (argc == 2) {
drm_directory = dirname(strdup(argv[1]));
node = basename(strdup(argv[1]));
}
dir_fd = open(drm_directory, O_RDONLY);
if (dir_fd < 0) {
printf("Directory open failed! (%s)\n", strerror(abs(dir_fd)));
return -1;
}
drm_fd = openat(dir_fd, node, O_RDWR);
if (drm_fd < 0) {
printf("Unable to open device! (%s)\n", strerror(abs(drm_fd)));
return -1;
}
gv = drmGetVersion(drm_fd);
if (gv <= 0) {
printf("Failure accessing DRM node! (Is it a DRM node?)\n");
return 1;
}
printf("Kernel module: %s\nDescription: %s\nDate: %s\n\n", gv->name, gv->desc, gv->date);
printf("Supported DRM IOCTL versions: ");
for (drm_major = 0; drm_major < INT_MAX; drm_major++) {
for (drm_minor = 0; drm_minor < INT_MAX; drm_minor++) {
sv.drm_di_major = drm_major;
sv.drm_di_minor = drm_minor;
sv.drm_dd_major = -1;
sv.drm_dd_minor = -1;
err = drmSetInterfaceVersion(drm_fd, &sv);
if (err == 0) {
printf("%d.%d ", drm_major, drm_minor);
} else {
if (drm_minor == 0 && drm_major > 0) {
if ( sv.drm_dd_major < 0 )
printf("NONE (%s)\n", strerror(abs(err)));
printf("\n");
goto out;
} else
break;
}
}
}
out:
printf("Driver version: %d.%d\n", sv.drm_dd_major, sv.drm_dd_minor);
drmFreeVersion(gv);
return 0;
}
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: R200 DRM/KMS
2015-07-08 16:48 ` Steven Newbury
@ 2015-07-08 22:44 ` Emil Velikov
2015-07-10 10:18 ` Steven John Newbury
0 siblings, 1 reply; 28+ messages in thread
From: Emil Velikov @ 2015-07-08 22:44 UTC (permalink / raw)
To: Steven Newbury; +Cc: Maling list - DRI developers
Hi Steven,
A couple of more (wild) ideas, below but first...
On 8 July 2015 at 17:48, Steven Newbury <steve@snewbury.org.uk> wrote:
> On Wed, 2015-07-08 at 17:10 +0100, Emil Velikov wrote:
>> On 8 July 2015 at 14:55, Alex Deucher <alexdeucher@gmail.com> wrote:
>> > On Wed, Jul 8, 2015 at 9:53 AM, Steven Newbury <
>> > steve@snewbury.org.uk> wrote:
>> > >
>> > >
>> > > On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
>> > > > On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury <
>> > > > steve@snewbury.org.uk> wrote:
>> > > > >
>> > > > >
>> > > > > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
>> > > > > > On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <
>> > > > > > steve@snewbury.org.uk> wrote:
>> > > > > > >
>> > > > > > > I've tried an xserver-1.16, and ddx, libdrm without LTO
>> > > > > > > and with
>> > > > > > > gcc4.9. Exactly the same thing. I wondered whether the
>> > > > > > > unused i810
>> > > > > > > could be interfering but triggering a device "remove"
>> > > > > > > before starting
>> > > > > > > X made no difference.
>> > > > > > >
I've completely missed out on this - you have a i810 in there ? Bth,
I'm not sure how well (if any) our userspace works when mixing UMS and
KMS drivers. Toggling off it in the BIOS, blacklisting the kernel
module, checking if it's the boot vga and if X gets it right are nice
things to test/try.
[snip]
> Sitting on a KMS console, "systemctl start gdm", no plymouth
> installed.
Don't know what gdm is up-to these days but a while back it used to
try bringing one X session for the greeter, quickly tear it down and
bring another one for the desktop. Not a gdm person so don't quote me
on that :-)
Yet if that is (roughly) still the case, a likely race condition is on.
> It's just during Xserver initialisation that
> drmSetInterfaceVersion() fails. AFAIK Xserver startup is entirely
> single process, single thread. I've written a little test utility
> which works fine on the system in question.
>
> Compile attached file with:
> gcc -O2 -o test-drm test-drm.c $(pkg-config --cflags libdrm) $(pkg
> -config --libs libdrm)
>
Your test utility seems to do a lot more than the few lines in
radeon_kms.c. Would it be possible that you're misinterpreted the
output (relative to the Xorg.log) ? I know I would :-)
>
>> Personally I would add a healthy amount of printk/printf though the
>> kernel drm + radeon and the ddx.
>
> I guess it doesn't really matter since patching out the code "fixes"
> it...
As you wish. Personally I tend to give it a bit more before giving up.
As this is getting a bit long/messy I'd suspect that a bugzilla entry
with information/logs might be good. It's up-to you, as I won't be
able to help much more.
Good luck,
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: R200 DRM/KMS
2015-07-08 22:44 ` Emil Velikov
@ 2015-07-10 10:18 ` Steven John Newbury
0 siblings, 0 replies; 28+ messages in thread
From: Steven John Newbury @ 2015-07-10 10:18 UTC (permalink / raw)
To: Emil Velikov; +Cc: Maling list - DRI developers
On Wed, 2015-07-08 at 23:44 +0100, Emil Velikov wrote:
...
>
> >
> > I guess it doesn't really matter since patching out the code
> > "fixes"
> > it...
> As you wish. Personally I tend to give it a bit more before giving
> up.
>
I typically would, but it isn't my machine, and my priority is getting
the system up as that's what I promised to do! Also, given there
doesn't really seem to be any point to the call to
drmSetInterfaceVersion(), as has been pointed out, simply removing it
doesn't hurt - although it admittedly irks me as to how/why it can be
failing.
> As this is getting a bit long/messy I'd suspect that a bugzilla entry
> with information/logs might be good. It's up-to you, as I won't be
> able to help much more.
Simply getting feedback has been helpful. Yes, I should open a
bugzilla entry, I'll get to it after I have the system up and running.
It's probably getting tough to maintain R200 support at this point,
particularly on ancient pre-millennial PCI only systems with buggy*
BIOSes! ;-)
* The BIOS option to disable the onboard video is present, and the help
test lists 3 options, Enabled - 512KB, Enabled - 1MB, Disabled. Only
the first two options actually appear on the menu! Even better, the
system only (re-)boots on the second attempt, first attempt always
hangs post-POST, before attempting to read from boot media!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 28+ messages in thread