Also got 945GME and have just upgraded to RC2 on my asus eeepc 1000h, so am using 2.8.0. X starts and runs fine, though feels a bit more sluggish in 2D graphics than before (and compared to 12.1 install on the same machine).

EDIT: using stock generic kernel

EDIT: realised bad performance was caused because I had forgotten about an xorg.conf I had been experimenting with a while back. All the problems disappeared when I deleted it.

glxgears is terrible, doesn't render correctly (transparent background) and visibly stutters and reports sub 60fps values (60Hz being the screen refresh rate).

Is it worth trying a 2.7.x intel driver?

Well, the packages are now official, thank you robby

kernel 2.6.31rc5, xf86-intel 2.8.0, latest mesa git as of now yields the best results for me.

I have the 945GM chipset.

Ut2004 at 1024x768 ran around 20-30fps which is as good as i get in windows.

I have an older pull of slackware-current but those are the only packages I updated.

mesa-git needs:

glew
mesa/src/mesa/drivers/dri/r200/radeon_screen.c needs a constant changed

I can't remember the name of the constant:
But I think I changed the follow.
R600_SCRATCH_REG_OFFSET ==> RADEON_SCRATCH_REG_OFFSET

And it compiled. I don't use radeon on this laptop.



l8r

In a post several hours ago, I noted that the upgraded/rebuilt X drivers had only a single problem. They did not create the /dev/dri/card node. But, I now have more serious problems. At random times that can not be correlated with any particular activity, any xterm or xterm ap receives the dreaded kernel message via the syslog daemon "Disabling IRQ #16"; this has the effect of slowing the entire CPU by orders of magnitude. (libata, eg, is on this interrupt). Upon appearance of this message, a total reboot is necessary.

I used the new X files to upgrade & all was fine. But, when I made a new installation on a new drive/partition these problems appeared.

This seems to be related to xorg-server (1.6.2 -> 1.6.3 ), xf86-video-intel (2.7.1 -> 2.8.0), mesa (7.4.4 -> 7.5), libdrm (2.11 -> 2.12). (Don't know about glew, pixmap, setxkbcmp, xkbcomp ...)

I'm on a Lenovo R61e with i965 chipset.

@mcnalu: yes, try the 2.7.1 intel driver, and perhaps try manually setting UXA accelmethod in xorg.conf.

@rdsherman: X isn't what creates /dev/dri/card* - that's the kernel drm module. Is this occurring in the stock 2.6.29.6 kernel? If so, what other customizations have you made to the system?

I'm using kernel 2.6.30.3, custom built, no modules.
AGP_INTEL & DRM_915 are set (KMS is not set).

From dmesg

[drm] Initialized drm 1.1.0 20060810
input: Video Bus as /devices/LNXSYSTM:00/device
:00/PNP0A08:00/device:02/input/input3
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

So DRM is setup by the kernel.

From my syslog

Aug 7 19:56:11 darkstar kernel:
[drm:i915_get_vblank_counter]
*ERROR* trying to get vblank count for disabled pipe 0

What does this mean?

The basic issue is that on Thr Aug 6 using the changelog I upgraded
only the newly rebuilt x pkgs for my i965/i915 system; nothing else
was altered. While the speed of everything X related improved
dramatically, some new problems have entered the game.

So far today in an all day test I've seen no other instablities.
I have not tested suspend to ram/disk.

I just want to report that with these latest packages, it is also possible to use kms with radeon, provided you have an appropriately configured 2.6.31rc kernel. It's supposably unstable code though but I do have fbo support when I tried it.

Thanks, will do.

I've had a nose around but can't find an 2.7.1 package. Can someone point me in the right direction please?

extra/xf86-video-intel-alternate

OK, my previous issues were down to an old xorg.conf that I had been playing with a while back. I deleted it and 2.8.0 worked v well for me.

2D seems fine.
ctrl-alt-F? switching works fine.
glxgears works ok, averaging about 120 fps.
extreme tux racer is playable and smooth.
googleearth works but is unusably slow.

Curiously, as someone else pointed out before, if I force software 3d rendering (e.g. by moving /usr/lib/modules/dri/i915_dri.so) googleearth becomes fast enough to be usable, tho still slow.

Spec: asus eeepc 1000h, intel 945GME, slackware 13 RC2, stock generic smp kernel, NO xorg.conf

I am not an expert in 3d standards, graphics and etc.

I am running up to date 64-current on Sony Vaio VGN-SR11MR which has (lspci -v):

01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400 Series (prog-if 00 [VGA controller])
Subsystem: Sony Corporation Device 9033
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at 80000000 (32-bit, prefetchable) [size=128M]
I/O ports at 9000 [size=256]
Memory at 88020000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 88000000 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information <?>

The only way dri would initialize and start for me is when I do this (exactly as written in the article):
http://www.x.org/wiki/radeonhd%3Aexperimental_3D

And this is what I get afterwards:

tolpekin@darkstar:~$ xdriinfo
Screen 0: r300


root@darkstar:/home/tolpekin# dmesg | grep drm
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized radeon 1.29.0 20080613 on minor 0
[drm] Used old pci detect: framebuffer loaded
[drm] Setting GART location based on new memory map
[drm] Loading RV620 CP Microcode
[drm] Loading RV620 PFP Microcode
[drm] Resetting GPU
[drm] writeback test succeeded in 1 usecs

tolpekin@darkstar:~$ glxinfo
Mesa: Mesa 7.6-devel DEBUG build Aug 15 2009 19:11:55
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
Mesa: Initializing x86-64 optimizations
GL_VERSION: 2.1 Mesa 7.6-devel
GL_EXTENSIONS: GL_ARB_copy_buffer GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_shading_language_120 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_shared_texture_palette GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_swizzle GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_3DFX_texture_compression_FXT1 GL_APPLE_packed_pixels GL_APPLE_vertex_array_object GL_ATI_blend_equation_separate GL_ATI_envmap_bumpmap GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_ATI_fragment_shader GL_ATI_separate_stencil GL_IBM_multimode_draw_arrays GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_resize_buffers GL_MESA_texture_array GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_fragment_program GL_NV_light_max_exponent GL_NV_point_sprite GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_NV_vertex_program1_1 GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGI_texture_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays
GL_RENDERER: Software Rasterizer
GL_VENDOR: Mesa Project
GLU_VERSION: 1.3
GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess
GLUT_API_VERSION: 5
GLUT_XLIB_IMPLEMENTATION: 15

tolpekin@darkstar:~$ glxgears
Mesa: Mesa 7.6-devel DEBUG build Aug 15 2009 19:11:55
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
Mesa: Initializing x86-64 optimizations
1141 frames in 5.004 seconds = 228.018 FPS

Not too much, but at least it is working. I think there is something wrong with my system and could be optimized.... Yeah, by the way I don't use xorg.conf and radeon driver is loaded. Maybe I should try radeonhd? But how can I do this without xorg.conf?

The 2.8.0 driver fails for me on an HP Compaq d530

X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0
Build Operating System: Slackware 13.0 Slackware Linux Project
Current Operating System: Linux evia 2.6.29.6-smp #2 SMP Sun Jul 12 22:46:36 CDT 2009 i686
Build Date: 03 August 2009 06:51:50PM

00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)

xorg.conf made by xorgsetup:
Section "Device"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
### [arg]: arg optional
#Option "NoAccel" # [<bool>]
#Option "SWcursor" # [<bool>]
#Option "ColorKey" # <i>
#Option "CacheLines" # <i>
#Option "Dac6Bit" # [<bool>]
#Option "DRI" # [<bool>]
#Option "NoDDC" # [<bool>]
#Option "ShowCache" # [<bool>]
#Option "XvMCSurfaces" # <i>
#Option "PageFlip" # [<bool>]
Identifier "Card0"
Driver "intel"
VendorName "Unknown Vendor"
BoardName "Unknown Board"
BusID "PCI:0:2:0"
EndSection

It loads into X, corrupted display, and a mouse pointer with nothing happening from the mouse buttons. Have to SSH in from another machine and reboot.

With Slackware 12.2, the intel810 server seemed to work OK. I upgraded via slackpkg to the -current today.

I tried some of the previous drivers from /extra but they didn't work either.

Suggestions?

Editing the autogenerated xorg.conf to add option for UXA allows it to get further into the server start-up process...
It gets into the KDE boot screen as far as showing the line of icons. Here's the tail end of the Xorg.0.log:
...and the tail end of dmesg...
AFAIK this is a bog-standard Slackware-current that arrived after a slackpkg upgrade of a fresh Slackware 12.2 install (I just got hold of the computer).

Having checked here:

http://intellinuxgraphics.org/2009Q2.html

...and noting the reference to: "drm-intel-2.6.30 branch"
...and having looked at a few forums on the intarw3bz, I don't think this will work without a late model 2.6.30 kernel or some kind of kernel patch tomfoolery.

The stock 2.6.29.6-smp is likely not going to cut it. I'm presuming Slack13 isn't going to uprev from this so we can declare it broken for at least some Intel vid chipset machines?

(Intel recommends "xserver-1.6.2" but one hopes 1.6.3 didn't break anything for the Intel driver.)

So, I downloaded the lastest stable kernel from kernel.org and compiled it using the .config from Slackware-current.

Using this and the 2.8.0 Intel driver from -current it gets a bit further on. It can actually fire up XFCE and load Mozilla and play a Youtube Flash video. However, trying to fire up Yakuake causes it to hang.

It certainly doesn't "just work" but it gets further on and maybe with some tweaking of the xorg.conf it will get somewhere. Or maybe re-building the driver. Or something. Or not.

X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0
Build Operating System: Slackware 13.0 Slackware Linux Project
Current Operating System: Linux evia 2.6.30.5-smp #1 SMP Mon Aug 17 12:46:26 BST 2009 i686
Build Date: 03 August 2009 06:51:50PM