mesa3d-users

Re: [Mesa3d-users] Mesa compilation using EABI toolchain

[iluvlinux <ilu...@gm...>]

EABI toolchain is new toolchain provided by ARM 
http://wiki.debian.org/ArmEabiPort http://wiki.debian.org/ArmEabiPort 

and clutter is a library that provides simple apis to users who don't know
about opengl and related stuff
http://clutter-project.org/ http://clutter-project.org/ 


I did a hexdump of some test images in totally red, or green or blue color,
and i found that the pixel values were accurate according to the images. I
have no idea were to look into mesa code. i did hexdump in clutter code just
before it calls glTexImage2D.


Here are some information related to EABI todo list
http://wiki.debian.org/ArmEabiTodo http://wiki.debian.org/ArmEabiTodo 


i have no idea about how to compile mesa with some different options ,all i
did to compile mesa is to type "make linux" and it builds cleanly.

if you could just help me out by providing some compile options if needed
with the new tool chain, i would be highly thankful to you. I know i am
asking something that is very difficult.

kindly help


thanks for your reply 
varun





Brian Paul wrote:
> 
> iluvlinux wrote:
>> hi
>> 
>> i compiled mesa with new Linux EABI toolchain 
>> i am using mesa as a libclutter backend
> 
> I've never heard of those things.
> 
> 
>> But when I try to run a application which contains some images (.jpg and
>> .pngs)
>>  i can only view some colored rectangles instead of images
>> 
>> earlier with gnuhash toolchain, the application runs fine, i just
>> switched
>> to new EABI toolchain and every thing messed up.
>> 
>> Also i want to know how mesa loads image file, it has its own
>> architecture
>> or it uses some other library as libjpeg etc.
> 
> Mesa is an implementation of OpenGL and has no functions for 
> reading/writing image files whatsoever.
> 
> Typically, a utility library is used to read/decompress an image file 
> into a malloc'd block of memory.  That memory/image can then be handed 
> to OpenGL via glTexImage, or glDrawPixels, etc. for rendering/drawing.
> 
> If you're working with jpegs, I suspect libjpeg is being used.
> 
> -Brian
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Mesa-compilation-using-EABI-toolchain-tp17799971p17820271.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] Mesa compilation using EABI toolchain

[Brian P. <bri...@tu...>]

iluvlinux wrote:
> hi
> 
> i compiled mesa with new Linux EABI toolchain 
> i am using mesa as a libclutter backend

I've never heard of those things.


> But when I try to run a application which contains some images (.jpg and
> .pngs)
>  i can only view some colored rectangles instead of images
> 
> earlier with gnuhash toolchain, the application runs fine, i just switched
> to new EABI toolchain and every thing messed up.
> 
> Also i want to know how mesa loads image file, it has its own architecture
> or it uses some other library as libjpeg etc.

Mesa is an implementation of OpenGL and has no functions for 
reading/writing image files whatsoever.

Typically, a utility library is used to read/decompress an image file 
into a malloc'd block of memory.  That memory/image can then be handed 
to OpenGL via glTexImage, or glDrawPixels, etc. for rendering/drawing.

If you're working with jpegs, I suspect libjpeg is being used.

-Brian

[Mesa3d-users] Mesa compilation using EABI toolchain

[iluvlinux <ilu...@gm...>]

hi

i compiled mesa with new Linux EABI toolchain 
i am using mesa as a libclutter backend

But when I try to run a application which contains some images (.jpg and
.pngs)
 i can only view some colored rectangles instead of images

earlier with gnuhash toolchain, the application runs fine, i just switched
to new EABI toolchain and every thing messed up.

Also i want to know how mesa loads image file, it has its own architecture
or it uses some other library as libjpeg etc.

kindly help
varun
-- 
View this message in context: http://www.nabble.com/Mesa-compilation-using-EABI-toolchain-tp17799971p17799971.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] GLSL fallback

[Brian P. <bri...@tu...>]

Christoph Harder wrote:
> Hello,
> 
> can I use Mesa3d to run GLSL shaders on Hardware that does not support OpenGL 2.0?

Yes.


> E.g. I would like to use GLSL on a Geforce 4 TI4400 128 MB, software rendering is fine, speed doesn't matter.

Software Mesa won't use your graphics hardware at all but will allow you 
to run any GLSL shader (modulo bugs).

> What is the easiest way to use Mesa on WindowsXP? MesaWinBinaries-6.0.zip from sourceforge?

I'd recommend Mesa 7.0.3, compiling it yourself.  Version 6.0 won't have 
GLSL support.

-Brian

[Mesa3d-users] GLSL fallback

[Christoph H. <sha...@ar...>]

Hello,

can I use Mesa3d to run GLSL shaders on Hardware that does not support OpenGL 2.0?
E.g. I would like to use GLSL on a Geforce 4 TI4400 128 MB, software rendering is fine, speed doesn't matter.

What is the easiest way to use Mesa on WindowsXP? MesaWinBinaries-6.0.zip from sourceforge?

Thanks in advance.
Christoph

Re: [Mesa3d-users] About Mesa7.0.3 install

[Brian P. <bri...@tu...>]

Guanghao Sun wrote:
> hello,
> 
> I try to install the Mesa7.0.3 to the linux(ubuntu8.0.4),
> But when I compiled the make file with the "make realclean"command.
> some errors given back just like  this
>  
>    makedepend: warning:  GLwDrawA.c, line 48: cannot find include file 
> "X11/IntrinsicP.h"
>     not in ../../include/X11/IntrinsicP.h
>     not in /usr/include/X11/IntrinsicP.h
> 
> please help me

You can usually ignore warnings.  Is there an error later?  If so, 
please post the _entire_ output.

-Brian

[Mesa3d-users] About Mesa7.0.3 install

[Guanghao S. <gua...@gm...>]

hello,

I try to install the Mesa7.0.3 to the linux(ubuntu8.0.4),
But when I compiled the make file with the "make realclean"command.
some errors given back just like  this

   makedepend: warning:  GLwDrawA.c, line 48: cannot find include file
"X11/IntrinsicP.h"
    not in ../../include/X11/IntrinsicP.h
    not in /usr/include/X11/IntrinsicP.h

please help me

best regards

Guanghao.Sun

Re: [Mesa3d-users] Mesa 7.1 release candidate 1

[Karl S. <k.w...@co...>]

On Wed, May 28, 2008 at 10:37 AM, sdc395 <mes...@de...>
wrote:

>
>
> Karl Schultz-2 wrote:
> >
> > I believe that the project dependencies are already in place.  Brian,
> this
> > was what the mesa.sln update was about that I sent you this week.  It was
> > missing ONE dependency.
> >
> > Perhaps "sdc395" can explain what is missing?
> >
> > Karl
> >
> My apologies.  I think I assumed some of my linking problems were down to
> build dependencies/order which was not defined in the 7.0.3 solution file.
> I should have checked.  RC1 is fine.  Sorry.
>
> However, I did need to add prog_uniform.c and prog_uniform.h to the mesa
> project file before gdi would build correctly.
>

Project files frequently get out of date as files are added.

Brian, I'm building the RC later today, and I'll send you the updated
project file, unless you've done it already.


> With regard to making contributions; I meant to ask how I go about
> submitting contributions rather than how to configure project dependencies.
>

I think start with mesa3d.org.  You also need to apply at
freedesktop.orgfor an account and I think that full instructions are
there.  Git is used
for the repository and was at one time hard to use from Windows.  I used to
submit changes myself until the switch to git.  Recently I've sent whatever
few changes I had to Brian.  But I think that the situation with git and
Windows has gotten better and I'll look into again if I ever intend to
update more than a few files.

>
> By the way, should I be posting these sorts of questions to mesa3d-dev or
> is
> this the right place?
>

I would guess talk about RC's on both, and "how to contribute" more on dev.

Karl

Re: [Mesa3d-users] Mesa 7.1 release candidate 1

[sdc395 <mes...@de...>]

Karl Schultz-2 wrote:
> 
> I believe that the project dependencies are already in place.  Brian, this
> was what the mesa.sln update was about that I sent you this week.  It was
> missing ONE dependency.
> 
> Perhaps "sdc395" can explain what is missing?
> 
> Karl
> 
My apologies.  I think I assumed some of my linking problems were down to
build dependencies/order which was not defined in the 7.0.3 solution file. 
I should have checked.  RC1 is fine.  Sorry.

However, I did need to add prog_uniform.c and prog_uniform.h to the mesa
project file before gdi would build correctly.

With regard to making contributions; I meant to ask how I go about
submitting contributions rather than how to configure project dependencies.

By the way, should I be posting these sorts of questions to mesa3d-dev or is
this the right place?

Simon
-- 
View this message in context: http://www.nabble.com/Mesa-7.1-release-candidate-1-tp17498578p17516913.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] Mesa 7.1 release candidate 1

[Karl S. <k.w...@co...>]

On Wed, May 28, 2008 at 10:01 AM, Brian Paul <
bri...@tu...> wrote:

> sdc395 wrote:
> > Brian Paul wrote:
> >>> Also, it would be nice to have the project dependencies configured in
> the
> >>> solution file.  It would save me having to do it every time I download
> a
> >>> new
> >>> version.
> >> I'm not familiar with that.  Maybe a Windows developer can contribute
> >> what's needed.
> >>
> > I'd happily contribute.  Could you point me in the direction of
> instructions
> > on how I go about this?
>
> I'm not a Windows developer so you probably know more about it than me.
>  Anyone else?
>
>
I believe that the project dependencies are already in place.  Brian, this
was what the mesa.sln update was about that I sent you this week.  It was
missing ONE dependency.

As it stands now, in the RC, mesa.sln has the following deps:

osmesa -> gdi
mesa -> <nothing>
glu-> gdi    (this is the one that was missing before Monday)
gdi -> mesa

There is also a defined project build order:

mesa
gdi
glu
osmesa

which seems correct to me.

Perhaps "sdc395" can explain what is missing?

Karl

Re: [Mesa3d-users] Mesa 7.1 release candidate 1

[Brian P. <bri...@tu...>]

sdc395 wrote:
> 
> Brian Paul wrote:
>> I'm attaching a new mesa.def file.  Could you please try it and see if 
>> that fixes these errors?
>>
> That new mesa.def file has done the trick - no more linking problems.

OK, it's in git and will be in the next release candidate.


> Brian Paul wrote:
>>> Also, it would be nice to have the project dependencies configured in the
>>> solution file.  It would save me having to do it every time I download a
>>> new
>>> version.
>> I'm not familiar with that.  Maybe a Windows developer can contribute 
>> what's needed.
>>
> I'd happily contribute.  Could you point me in the direction of instructions
> on how I go about this?

I'm not a Windows developer so you probably know more about it than me. 
  Anyone else?


> Brian Paul wrote:
>>> Might this release have addressed the heap corruption issue I reported?
>> Can you remind me what that was?  Did you file a bug report?
>>
> 
> That was  http://www.nabble.com/Heap-Corruption--to16558747.html this issue
> .  I was hoping someone would attempt to recreate the problem before I took
> it any further.  I'm wondering if it is related to 
> http://www.nabble.com/Using-QGLWidget-with-MESA-to17514038.html this one .

If this were on Linux, I'd use valgrind to track down the problem.  I 
think Purify would be the Windows equivalent.

-Brian

Re: [Mesa3d-users] Mesa 7.1 release candidate 1

[sdc395 <mes...@de...>]

Brian Paul wrote:
> 
> I'm attaching a new mesa.def file.  Could you please try it and see if 
> that fixes these errors?
> 
That new mesa.def file has done the trick - no more linking problems.


Brian Paul wrote:
> 
>> Also, it would be nice to have the project dependencies configured in the
>> solution file.  It would save me having to do it every time I download a
>> new
>> version.
> 
> I'm not familiar with that.  Maybe a Windows developer can contribute 
> what's needed.
> 
I'd happily contribute.  Could you point me in the direction of instructions
on how I go about this?


Brian Paul wrote:
> 
>> Might this release have addressed the heap corruption issue I reported?
> 
> Can you remind me what that was?  Did you file a bug report?
> 

That was  http://www.nabble.com/Heap-Corruption--to16558747.html this issue
.  I was hoping someone would attempt to recreate the problem before I took
it any further.  I'm wondering if it is related to 
http://www.nabble.com/Using-QGLWidget-with-MESA-to17514038.html this one .
-- 
View this message in context: http://www.nabble.com/Mesa-7.1-release-candidate-1-tp17498578p17515986.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] Mesa 7.1 release candidate 1

[Brian P. <bri...@tu...>]

Benno Schulenberg wrote:
> Brian Paul wrote:
>> The first release candidate of Mesa 7.1 (new development release)
>> can be grabbed from http://www.mesa3d.org/beta
> 
> Where do I find a packaged libdrm-2.3.1 or higher to go with it?  
> Gentoo doesn't seem to have it yet.

I think Dave Airlie is still working on it...

-Brian

Re: [Mesa3d-users] Mesa 7.1 release candidate 1

[Brian P. <bri...@tu...>]

sdc395 wrote:
> I've attempted to build 7.1 RC 1 using Visual Studio 2005 and can report the
> following issues...
> 
> Building mesa...
> 
> 
>> \src\mesa\main\texcompress_fxt1.c(668) : warning C4293: '<<' : shift count
>> negative or too big, undefined behavior
>> \src\mesa\main\texcompress_fxt1.c(715) : warning C4293: '<<' : shift count
>> negative or too big, undefined behavior
>> \src\mesa\main\texcompress_fxt1.c(721) : warning C4293: '<<' : shift count
>> negative or too big, undefined behavior
>> \src\mesa\main\texcompress_fxt1.c(886) : warning C4293: '<<' : shift count
>> negative or too big, undefined behavior
>> \src\mesa\main\texcompress_fxt1.c(892) : warning C4293: '<<' : shift count
>> negative or too big, undefined behavior
>> \src\mesa\main\texcompress_fxt1.c(1106) : warning C4293: '<<' : shift
>> count negative or too big, undefined behavior
>> \src\mesa\main\texcompress_fxt1.c(1275) : warning C4293: '<<' : shift
>> count negative or too big, undefined behavior
>>
> 
> Can't Fx64 by typedef'd as unsigned __int64 rather then using that generic
> struct solution?

The code in that file should probably just be rewritten to use the 
GLuint64EXT type that's defined in glext.h.  I may take a stab at that 
later.


> 
> Building gdi...
> 
> 
>> \src\mesa\drivers\windows\gdi\wgl.c(606) : warning C4013:
>> 'WMesaShareLists' undefined; assuming extern returning int
>>
>> mesa.def : error LNK2001: unresolved external symbol _mesa_attach_shader
>> mesa.def : error LNK2001: unresolved external symbol
>> _mesa_bind_attrib_location
>> mesa.def : error LNK2001: unresolved external symbol _mesa_compile_shader
>> mesa.def : error LNK2001: unresolved external symbol _mesa_create_program
>> mesa.def : error LNK2001: unresolved external symbol _mesa_create_shader
>> mesa.def : error LNK2001: unresolved external symbol _mesa_delete_program2
>> mesa.def : error LNK2001: unresolved external symbol _mesa_delete_shader
>> mesa.def : error LNK2001: unresolved external symbol _mesa_detach_shader
>> mesa.def : error LNK2001: unresolved external symbol
>> _mesa_get_active_attrib
>> mesa.def : error LNK2001: unresolved external symbol
>> _mesa_get_active_uniform
>> mesa.def : error LNK2001: unresolved external symbol
>> _mesa_get_attached_shaders
>> mesa.def : error LNK2001: unresolved external symbol
>> _mesa_get_attrib_location
>> mesa.def : error LNK2001: unresolved external symbol _mesa_get_handle
>> mesa.def : error LNK2001: unresolved external symbol
>> _mesa_get_program_info_log
>> mesa.def : error LNK2001: unresolved external symbol _mesa_get_programiv
>> mesa.def : error LNK2001: unresolved external symbol
>> _mesa_get_shader_info_log
>> mesa.def : error LNK2001: unresolved external symbol
>> _mesa_get_shader_source
>> mesa.def : error LNK2001: unresolved external symbol _mesa_get_shaderiv
>> mesa.def : error LNK2001: unresolved external symbol
>> _mesa_get_uniform_location
>> mesa.def : error LNK2001: unresolved external symbol _mesa_get_uniformfv
>> mesa.def : error LNK2001: unresolved external symbol _mesa_is_program
>> mesa.def : error LNK2001: unresolved external symbol _mesa_is_shader
>> mesa.def : error LNK2001: unresolved external symbol _mesa_link_program
>> mesa.def : error LNK2001: unresolved external symbol _mesa_shader_source
>> mesa.def : error LNK2001: unresolved external symbol _mesa_uniform
>> mesa.def : error LNK2001: unresolved external symbol _mesa_uniform_matrix
>> mesa.def : error LNK2001: unresolved external symbol
>> _mesa_validate_program
>>
> 
> All of those unresolved functions are defined as static in shader_api.c

I'm attaching a new mesa.def file.  Could you please try it and see if 
that fixes these errors?



> Also, it would be nice to have the project dependencies configured in the
> solution file.  It would save me having to do it every time I download a new
> version.

I'm not familiar with that.  Maybe a Windows developer can contribute 
what's needed.


> Might this release have addressed the heap corruption issue I reported?

Can you remind me what that was?  Did you file a bug report?

-Brian

[Mesa3d-users] Using QGLWidget with MESA

[Thomas H. <tho...@ig...>]

Hi there,

I'm trying to do software-based OpenGL rendering in a QGLWidget under 
Windows. Thus I've tried to use MESA 7.0.3 as OpenGL software renderer.

Using GLUT applications in conjunction with MESA works fine, as long as 
I don't use extensions that are not supported by MESA...

But with Qt applications the render area remains black. I tried to find 
out what the problem is using the hellogl example of Qt 4.3.3. It seems 
something goes wrong on the heap when allocating memory for the render 
context. But I have no clue what exactly happens and what goes wrong...

Any ideas?

Thanks,
Thomas

Re: [Mesa3d-users] Mesa 7.1 release candidate 1

[sdc395 <mes...@de...>]

The following functions also appear to be missing from mesa.def...


> _mesa_init_glsl_driver_functions
> _mesa_generate_mipmap
> _mesa_enable_2_1_extensions
> _mesa_enable_2_0_extensions
> 

-- 
View this message in context: http://www.nabble.com/Mesa-7.1-release-candidate-1-tp17498578p17510116.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] Mesa 7.1 release candidate 1

[sdc395 <mes...@de...>]

I've attempted to build 7.1 RC 1 using Visual Studio 2005 and can report the
following issues...

Building mesa...


> \src\mesa\main\texcompress_fxt1.c(668) : warning C4293: '<<' : shift count
> negative or too big, undefined behavior
> \src\mesa\main\texcompress_fxt1.c(715) : warning C4293: '<<' : shift count
> negative or too big, undefined behavior
> \src\mesa\main\texcompress_fxt1.c(721) : warning C4293: '<<' : shift count
> negative or too big, undefined behavior
> \src\mesa\main\texcompress_fxt1.c(886) : warning C4293: '<<' : shift count
> negative or too big, undefined behavior
> \src\mesa\main\texcompress_fxt1.c(892) : warning C4293: '<<' : shift count
> negative or too big, undefined behavior
> \src\mesa\main\texcompress_fxt1.c(1106) : warning C4293: '<<' : shift
> count negative or too big, undefined behavior
> \src\mesa\main\texcompress_fxt1.c(1275) : warning C4293: '<<' : shift
> count negative or too big, undefined behavior
> 

Can't Fx64 by typedef'd as unsigned __int64 rather then using that generic
struct solution?

Building gdi...


> \src\mesa\drivers\windows\gdi\wgl.c(606) : warning C4013:
> 'WMesaShareLists' undefined; assuming extern returning int
> 
> mesa.def : error LNK2001: unresolved external symbol _mesa_attach_shader
> mesa.def : error LNK2001: unresolved external symbol
> _mesa_bind_attrib_location
> mesa.def : error LNK2001: unresolved external symbol _mesa_compile_shader
> mesa.def : error LNK2001: unresolved external symbol _mesa_create_program
> mesa.def : error LNK2001: unresolved external symbol _mesa_create_shader
> mesa.def : error LNK2001: unresolved external symbol _mesa_delete_program2
> mesa.def : error LNK2001: unresolved external symbol _mesa_delete_shader
> mesa.def : error LNK2001: unresolved external symbol _mesa_detach_shader
> mesa.def : error LNK2001: unresolved external symbol
> _mesa_get_active_attrib
> mesa.def : error LNK2001: unresolved external symbol
> _mesa_get_active_uniform
> mesa.def : error LNK2001: unresolved external symbol
> _mesa_get_attached_shaders
> mesa.def : error LNK2001: unresolved external symbol
> _mesa_get_attrib_location
> mesa.def : error LNK2001: unresolved external symbol _mesa_get_handle
> mesa.def : error LNK2001: unresolved external symbol
> _mesa_get_program_info_log
> mesa.def : error LNK2001: unresolved external symbol _mesa_get_programiv
> mesa.def : error LNK2001: unresolved external symbol
> _mesa_get_shader_info_log
> mesa.def : error LNK2001: unresolved external symbol
> _mesa_get_shader_source
> mesa.def : error LNK2001: unresolved external symbol _mesa_get_shaderiv
> mesa.def : error LNK2001: unresolved external symbol
> _mesa_get_uniform_location
> mesa.def : error LNK2001: unresolved external symbol _mesa_get_uniformfv
> mesa.def : error LNK2001: unresolved external symbol _mesa_is_program
> mesa.def : error LNK2001: unresolved external symbol _mesa_is_shader
> mesa.def : error LNK2001: unresolved external symbol _mesa_link_program
> mesa.def : error LNK2001: unresolved external symbol _mesa_shader_source
> mesa.def : error LNK2001: unresolved external symbol _mesa_uniform
> mesa.def : error LNK2001: unresolved external symbol _mesa_uniform_matrix
> mesa.def : error LNK2001: unresolved external symbol
> _mesa_validate_program
> 

All of those unresolved functions are defined as static in shader_api.c

Also, it would be nice to have the project dependencies configured in the
solution file.  It would save me having to do it every time I download a new
version.

Might this release have addressed the heap corruption issue I reported?


Brian Paul wrote:
> 
> 
> The first release candidate of Mesa 7.1 (new development release) can be 
> grabbed from http://www.mesa3d.org/beta
> 
> This has been tagged in git as mesa_7_1_rc1
> 
> There's a lot of new code, the new auto-conf build system, etc. so it's 
> important that people grab these tarballs and test.
> 
> 
> -Brian
> 

-- 
View this message in context: http://www.nabble.com/Mesa-7.1-release-candidate-1-tp17498578p17508617.html
Sent from the mesa3d-users mailing list archive at Nabble.com.

Re: [Mesa3d-users] Mesa 7.1 release candidate 1

[Benno S. <ben...@ju...>]

Brian Paul wrote:
> The first release candidate of Mesa 7.1 (new development release)
> can be grabbed from http://www.mesa3d.org/beta

Where do I find a packaged libdrm-2.3.1 or higher to go with it?  
Gentoo doesn't seem to have it yet.

Benno

[Mesa3d-users] Mesa 7.1 release candidate 1

[Brian P. <bri...@tu...>]

The first release candidate of Mesa 7.1 (new development release) can be 
grabbed from http://www.mesa3d.org/beta

This has been tagged in git as mesa_7_1_rc1

There's a lot of new code, the new auto-conf build system, etc. so it's 
important that people grab these tarballs and test.


-Brian

[Mesa3d-users] LIBGL_DEBUG=verbose glxinfo doesn't work

[Mikko C. <mik...@gm...>]

Hi,
I'm trying to understand why DRI isn't working, so I run:
LIBGL_DEBUG=verbose glxinfo

But it gives me the exact same output as "glxinfo".
Why is that?
I run Gentoo amd64, MesaProgs-7.0.3, and Mesa from git (r500-support 
branch) with debug flag enabled.
Can anyone help me?
Thanks

Mikko C.

Re: [Mesa3d-users] sample_server fails to start with radeon driver - fbdev/DRI - linux-solo

[S. P. <pr...@gm...>]

I had a look at the gentoo-wiki, sounds quite complicated and Arch Linux
doesn't feel too well with it...
Anyway, I accidentally deleted my whole working directory today... and so i
had to compile fbdev/DRI once again.
Now the sample_server starts with the same output without errors, screen
goes black and font goes dark grey, but i can exit the sample_server with
Ctrl+C when using ssh.
Soon I try to start sample_server again I get this output:

[root@server miniglx]# ./sample_server & ./miniglxtest
[miniglx] probed chipset 0x4e48
got MMIOAddress 0xb7fad000 offset 134217728
shared virtual width is 1280
[drm] drmSetBusid failed (5, PCI:1:0:0), Device or resource busy
__miniglx_StartServer: __driInitFBDev failed
Error: __miniglx_StartServer failed
[2] 15643
[miniglx] probed chipset 0x4e48
CreateNotify
Authorize - magic 4
xf86-video-ati-6.6.2 or newer needed for Radeon 9500/9700/9800 cards.
libGL error: InitDriver failed
libGL error: reverting to (slow) indirect rendering
XOpenDisplay: __driCreateScreen failed
Error: XOpenDisplay failed
DestroyNotify
[2]+  Exit 1                  ./sample_server



I tried to install the new driver from here
http://xorg.freedesktop.org/releases/individual/driver/ but the error stays
the same - even after rebooting.

Running ./sample_server alone results in:
[root@server miniglx]# ./sample_server
[miniglx] probed chipset 0x4e48
got MMIOAddress 0xb7df4000 offset 134217728
shared virtual width is 1280
[drm] drmSetBusid failed (5, PCI:1:0:0), Device or resource busy
__miniglx_StartServer: __driInitFBDev failed
Error: __miniglx_StartServer failed

Running ./miniglxtest alone results in:
[root@server miniglx]# ./miniglxtest
[miniglx] probed chipset 0x4e48
CreateNotify
Authorize - magic 8
xf86-video-ati-6.6.2 or newer needed for Radeon 9500/9700/9800 cards.
libGL error: InitDriver failed
libGL error: reverting to (slow) indirect rendering
XOpenDisplay: __driCreateScreen failed
Error: XOpenDisplay failed
DestroyNotify

Whenever I load the module radeonfb the screen goes black and the font
re-appears much smaller after a few seconds, it seems the screen uses a
better screen resolution soon i modprobe radeonfb.

What exactly is not working? The Framebuffer? The Framebuffer-Driver? fbdev?
The example-tools?
The parts of the kernel I should activate when following
http://gentoo-wiki.com/HOWTO_Framebuffer_Support are activated here under my
Arch Linux - but due to using Lilo as Bootloader i didn't manage to boot
with the boot-options listed in the gentoo wiki...
I'll try it later on, maybe i'll install grub...

Thanks, Maurizio

On Mon, May 19, 2008 at 3:23 PM, Maurizio Rottin <mau...@gm...>
wrote:

> 2008/5/19, Simon Prückl <pr...@gm...>:
> > I'm on x86, yes. I compiled the kernel using the manual from the official
> > Arch Linux Wiki, I used the old config and just changed the 2 lines the
> > manual told me to do.
> > I don't know anything about the framebuffer - when starting the
> > sample_server without module radeonfb loaded he complains there's no
> > /dev/fb0, after modprobe radeonfb it "works" and results in the output
> > posted 2 mails ago (see below).
>
> so the problem is the framebuffer module, not mesa.
> in my gentoo i had to build ati-drivers, plus build uvesafb (couse
> vesafb does not work anymore since 2.6.22 i believe), then rebuild the
> kernel with the path to an initrd ad hoc and klibc to make it work
> http://gentoo-wiki.com/HOWTO_Framebuffer_Support
>
> --
> mr
>

Re: [Mesa3d-users] sample_server fails to start with radeon driver - fbdev/DRI - linux-solo

[S. P. <pr...@gm...>]

I'm on x86, yes. I compiled the kernel using the manual from the official
Arch Linux Wiki, I used the old config and just changed the 2 lines the
manual told me to do.
I don't know anything about the framebuffer - when starting the
sample_server without module radeonfb loaded he complains there's no
/dev/fb0, after modprobe radeonfb it "works" and results in the output
posted 2 mails ago (see below).
Running fbset -i results in this output:
[root@server tools]# fbset -i

mode "1280x1024-60"
    # D: 108.003 MHz, H: 63.983 kHz, V: 60.021 Hz
    geometry 1280 1024 1280 1024 8
    timings 9259 248 48 38 1 112 3
    hsync high
    vsync high
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : ATI Radeon NH
    Address     : 0xe8000000
    Size        : 134217728
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 1280
    MMIO Address: 0xfe9f0000
    MMIO Size   : 16384
    Accelerator : Unknown (38)



[root@server miniglx]# ./sample_server && ./miniglx
[miniglx] probed chipset 0x4e48
got MMIOAddress 0xb7e45000 offset 134217728
shared virtual width is 1024
[drm] added 8192 byte SAREA at 0xf89cc000
[drm] mapped SAREA 0xf89cc000 to 0xb7e43000, size 8192
[drm] framebuffer handle = 0xe8000000
[drm] register handle = 0xfe9f0000
[gart] AGP enabled at 1x
[gart] 8192 kB allocated with handle 0x00000001
[gart] ring handle = 0xf8000000
[gart] ring read ptr handle = 0xf8101000
[gart] vertex/indirect buffers handle = 0xf8102000
[gart] AGP texture map handle = 0xf8302000
Using 8 MB AGP aperture
Using 1 MB for the ring buffer
Using 2 MB for vertex/indirect buffers
Using 1 MB for AGP textures
Will use back buffer at offset 0x400000
Will use depth buffer at offset 0x700000
Will use 120832 kb for textures at offset 0xa00000
[drm] Added 32 65536 byte vertex/indirect buffers
[drm] dma control initialized, using IRQ 16
[drm] Initialized kernel gart heap manager, 5111808
color tiling disabled
page flipping disabled
[miniglx] Setting mode: visible 1024x768 virtual 1024x768x32
[miniglx] Readback mode: visible 1024x768 virtual 1024x768x32
RADEONEngineRestore

On Mon, May 19, 2008 at 2:44 PM, Maurizio Rottin <mau...@gm...>
wrote:

> 2008/5/18, Simon Prückl <pr...@gm...>:
> > I want to add that the screen is NOT only black as I told you a few hours
> > ago, it's black and there's (barely visible in dark grey) the output of
> > console.
> > Changing to 16bit color depth results in a violet font.
> >  In any case it's a total lock-up.
>
> are you on x86 architecture, and compiled the kernel (and framebuffer)
> by yourself?
>
> --
> mr
>



-- 
Simon Prückl - Prüxxx - Krift 43 - 4550 Kremsmünster

Re: [Mesa3d-users] sample_server fails to start with radeon driver - fbdev/DRI - linux-solo

[S. P. <pr...@gm...>]

I want to add that the screen is NOT only black as I told you a few hours
ago, it's black and there's (barely visible in dark grey) the output of
console.
Changing to 16bit color depth results in a violet font.
In any case it's a total lock-up.

Does anyone know what could be wrong here?
Regards



On Sun, May 18, 2008 at 5:21 PM, Simon Prückl <pr...@gm...> wrote:

> Ok, I fixed that problem, the file radeon_dri.so should have been in
> /usr/lib/xorg/modules/dri/radeon_dri.so .
> So I'm able to start the sample_server, but the only thing I get is a black
> screen.
>
> I cannot change to other framebuffer consoles, my ssh-session gets stuck,
> the only thing i can do is to reboot.
>
> When starting via SSH i get this output:
> [root@server miniglx]# ./sample_server && ./miniglx
> [miniglx] probed chipset 0x4e48
> got MMIOAddress 0xb7e45000 offset 134217728
> shared virtual width is 1024
> [drm] added 8192 byte SAREA at 0xf89cc000
> [drm] mapped SAREA 0xf89cc000 to 0xb7e43000, size 8192
> [drm] framebuffer handle = 0xe8000000
> [drm] register handle = 0xfe9f0000
> [gart] AGP enabled at 1x
> [gart] 8192 kB allocated with handle 0x00000001
> [gart] ring handle = 0xf8000000
> [gart] ring read ptr handle = 0xf8101000
> [gart] vertex/indirect buffers handle = 0xf8102000
> [gart] AGP texture map handle = 0xf8302000
> Using 8 MB AGP aperture
> Using 1 MB for the ring buffer
> Using 2 MB for vertex/indirect buffers
> Using 1 MB for AGP textures
> Will use back buffer at offset 0x400000
> Will use depth buffer at offset 0x700000
> Will use 120832 kb for textures at offset 0xa00000
> [drm] Added 32 65536 byte vertex/indirect buffers
> [drm] dma control initialized, using IRQ 16
> [drm] Initialized kernel gart heap manager, 5111808
> color tiling disabled
> page flipping disabled
> [miniglx] Setting mode: visible 1024x768 virtual 1024x768x32
> [miniglx] Readback mode: visible 1024x768 virtual 1024x768x32
> RADEONEngineRestore
>
> When starting at the PC itself i get a black screen.
>
> I don't know what's wrong, maybe i'll play with the settings a little bit,
> but if anyone has experienced something like that, please help...
>
> Regards
>
>
> On Sun, May 18, 2008 at 3:50 PM, Simon Prückl <pr...@gm...> wrote:
>
>> Hoi,
>>
>> I finally managed to compile mesa with linux-solo configuration after a
>> few weeks of trial-and-error.
>> Now whenever i try to start the sample_server I get this error:
>>
>> [root@server miniglx]# ./sample_server &
>> [miniglx] probed chipset 0x4e48
>> got MMIOAddress 0xb7df4000 offset 134217728
>> Unable to open radeon_dri.so: radeon_dri.so: cannot open shared object
>> file: No such file or directory
>> InitDriver failed
>> Error: __miniglx_StartServer failed
>> [1] 3325
>> [1]+  Exit 1                  ./sample_server
>>
>> I am using Arch Linux with 2.6.25 kernel and modifications regarding the
>> file drm_drv.c
>> Video Card is ATI Radeon 9800, modules radeon, radeofb, agpgart are
>> loaded.
>>
>> I have absolutly no idea why he refuses to find radeon_dri.so, the file
>> exists in
>> /usr/X11R6/lib/modules/dri/radeon_dri.so
>> and
>> /usr/lib/dri/radeon_dri.so
>>
>> (and of course in /root/Mesa-7.0.3/lib/radeon_dri.so and
>> /root/Mesa-7.0.3/src/mesa/drivers/dri/radeon/radeon_dri.so)
>>
>> If it should be somewhere else - please tell me.
>>
>> If there's any other reason why it refuses to work, please tell me. I've
>> absolutly no idea what could be wrong, I need your help.
>>
>> Regards,
>> Simon Prückl
>>
>
>
>
> --
> Simon Prückl - Prüxxx - Krift 43 - 4550 Kremsmünster
>



-- 
Simon Prückl - Prüxxx - Krift 43 - 4550 Kremsmünster

Re: [Mesa3d-users] sample_server fails to start with radeon driver - fbdev/DRI - linux-solo

[S. P. <pr...@gm...>]

Ok, I fixed that problem, the file radeon_dri.so should have been in
/usr/lib/xorg/modules/dri/radeon_dri.so .
So I'm able to start the sample_server, but the only thing I get is a black
screen.

I cannot change to other framebuffer consoles, my ssh-session gets stuck,
the only thing i can do is to reboot.

When starting via SSH i get this output:
[root@server miniglx]# ./sample_server && ./miniglx
[miniglx] probed chipset 0x4e48
got MMIOAddress 0xb7e45000 offset 134217728
shared virtual width is 1024
[drm] added 8192 byte SAREA at 0xf89cc000
[drm] mapped SAREA 0xf89cc000 to 0xb7e43000, size 8192
[drm] framebuffer handle = 0xe8000000
[drm] register handle = 0xfe9f0000
[gart] AGP enabled at 1x
[gart] 8192 kB allocated with handle 0x00000001
[gart] ring handle = 0xf8000000
[gart] ring read ptr handle = 0xf8101000
[gart] vertex/indirect buffers handle = 0xf8102000
[gart] AGP texture map handle = 0xf8302000
Using 8 MB AGP aperture
Using 1 MB for the ring buffer
Using 2 MB for vertex/indirect buffers
Using 1 MB for AGP textures
Will use back buffer at offset 0x400000
Will use depth buffer at offset 0x700000
Will use 120832 kb for textures at offset 0xa00000
[drm] Added 32 65536 byte vertex/indirect buffers
[drm] dma control initialized, using IRQ 16
[drm] Initialized kernel gart heap manager, 5111808
color tiling disabled
page flipping disabled
[miniglx] Setting mode: visible 1024x768 virtual 1024x768x32
[miniglx] Readback mode: visible 1024x768 virtual 1024x768x32
RADEONEngineRestore

When starting at the PC itself i get a black screen.

I don't know what's wrong, maybe i'll play with the settings a little bit,
but if anyone has experienced something like that, please help...

Regards

On Sun, May 18, 2008 at 3:50 PM, Simon Prückl <pr...@gm...> wrote:

> Hoi,
>
> I finally managed to compile mesa with linux-solo configuration after a few
> weeks of trial-and-error.
> Now whenever i try to start the sample_server I get this error:
>
> [root@server miniglx]# ./sample_server &
> [miniglx] probed chipset 0x4e48
> got MMIOAddress 0xb7df4000 offset 134217728
> Unable to open radeon_dri.so: radeon_dri.so: cannot open shared object
> file: No such file or directory
> InitDriver failed
> Error: __miniglx_StartServer failed
> [1] 3325
> [1]+  Exit 1                  ./sample_server
>
> I am using Arch Linux with 2.6.25 kernel and modifications regarding the
> file drm_drv.c
> Video Card is ATI Radeon 9800, modules radeon, radeofb, agpgart are loaded.
>
> I have absolutly no idea why he refuses to find radeon_dri.so, the file
> exists in
> /usr/X11R6/lib/modules/dri/radeon_dri.so
> and
> /usr/lib/dri/radeon_dri.so
>
> (and of course in /root/Mesa-7.0.3/lib/radeon_dri.so and
> /root/Mesa-7.0.3/src/mesa/drivers/dri/radeon/radeon_dri.so)
>
> If it should be somewhere else - please tell me.
>
> If there's any other reason why it refuses to work, please tell me. I've
> absolutly no idea what could be wrong, I need your help.
>
> Regards,
> Simon Prückl
>



-- 
Simon Prückl - Prüxxx - Krift 43 - 4550 Kremsmünster

[Mesa3d-users] sample_server fails to start with radeon driver - fbdev/DRI - linux-solo

[S. P. <pr...@gm...>]

Hoi,

I finally managed to compile mesa with linux-solo configuration after a few
weeks of trial-and-error.
Now whenever i try to start the sample_server I get this error:

[root@server miniglx]# ./sample_server &
[miniglx] probed chipset 0x4e48
got MMIOAddress 0xb7df4000 offset 134217728
Unable to open radeon_dri.so: radeon_dri.so: cannot open shared object file:
No such file or directory
InitDriver failed
Error: __miniglx_StartServer failed
[1] 3325
[1]+  Exit 1                  ./sample_server

I am using Arch Linux with 2.6.25 kernel and modifications regarding the
file drm_drv.c
Video Card is ATI Radeon 9800, modules radeon, radeofb, agpgart are loaded.

I have absolutly no idea why he refuses to find radeon_dri.so, the file
exists in
/usr/X11R6/lib/modules/dri/radeon_dri.so
and
/usr/lib/dri/radeon_dri.so

(and of course in /root/Mesa-7.0.3/lib/radeon_dri.so and
/root/Mesa-7.0.3/src/mesa/drivers/dri/radeon/radeon_dri.so)

If it should be somewhere else - please tell me.

If there's any other reason why it refuses to work, please tell me. I've
absolutly no idea what could be wrong, I need your help.

Regards,
Simon Prückl