search for: 16bpp

On Fri, Jul 06, 2018 at 02:35:07PM -0400, Adam Jackson wrote: > On Fri, 2018-07-06 at 11:12 +0200, Gerd Hoffmann wrote: > > cirrus can handle 1024x768 (and slightly higher) with 24bpp depth. > > cirrus can handle up to 800x600 with 32bpp. > > 16bpp is maybe a better choice? Nobody's using cirrus because they care > about color fidelity and it'll use less CPU to update. There's > precedent here, mgag200 defaults to 16bpp on sufficiently memory- > impaired devices. Yeah nouveau does the same fallback to 16bpp if there'...

The problem with 24bpp is that it is a rather unusual depth these days, cirrus is pretty much the only relevant device still using that, and it is a endless source of issues. Wayland doesn't support it at all. Bugs in Xorg keep showing up. Typically either 32bpp or 16bpp are used. Using 32bpp would limit the resolution to 800x600 due to hardware constrains. So lets go with 16bpp. Also use the default depth for the framebuffer console. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus_drv.c | 4 ++-- drivers/gpu/drm/c...

The problem with 24bpp is that it is a rather unusual depth these days, cirrus is pretty much the only relevant device still using that, and it is a endless source of issues. Wayland doesn't support it at all. Bugs in Xorg keep showing up. Typically either 32bpp or 16bpp are used. Using 32bpp would limit the resolution to 800x600 due to hardware constrains. So lets go with 16bpp. Also use the default depth for the framebuffer console and mode_info->preferred_depth. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus_d...

...sp: 0870: 0000e900 -> 0000e800 > > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 > > nouveau 0000:02:00.0: disp: 0878: 00000000 > > nouveau 0000:02:00.0: disp: 0880: 05000000 > > > > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in > > 64MB case. Why? > > > > I get blank screen even with 64MB with video=1280x1024-8 kernel > > parameter. Console works with video=1280x1024-16 even with 32MB stolen > > memory. > > > > Conclusions: 8-bit support is broken and bpp reduction is...

hi, a small patch inspired from Kristian H?gsberg compiz-aiglx patch, to use compiz with xorg aiglx with tftp_damage patch and gl-include-inferior patch. this patch add command-line option to force bind and release whenever the texture is used. to use it you must start xorg in 16 depth mode, and start compiz with LIBGL_ALWAYS_INDIRECT environnement variable PS : sorry for my bad english

So, I am having a problem running this game I installed in the virtual drive created by Wine. I am new to running anything through wine. My current OS is Ubuntu 10.04 and the version of Wine that I am using is 1.1.43. The game seems to crash before I can even open it. This is the information I have so far: fixme:reg:GetNativeSystemInfo (0x33fe40) using GetSystemInfo()

https://bugs.freedesktop.org/show_bug.cgi?id=42384 Bug #: 42384 Summary: X fails on NV11 with Error allocating scanout buffer: 0 Classification: Unclassified Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium

...;>> > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 >>> > nouveau 0000:02:00.0: disp: 0878: 00000000 >>> > nouveau 0000:02:00.0: disp: 0880: 05000000 >>> > >>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in >>> > 64MB case. Why? >>> > >>> > I get blank screen even with 64MB with video=1280x1024-8 kernel >>> > parameter. Console works with video=1280x1024-16 even with 32MB stolen >>> > memory. >>> > >>> > Co...

...;>> > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 >>> > nouveau 0000:02:00.0: disp: 0878: 00000000 >>> > nouveau 0000:02:00.0: disp: 0880: 05000000 >>> > >>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in >>> > 64MB case. Why? >>> > >>> > I get blank screen even with 64MB with video=1280x1024-8 kernel >>> > parameter. Console works with video=1280x1024-16 even with 32MB stolen >>> > memory. >>> > >>> > Co...

On Fri, Apr 07, 2017 at 10:29:00AM +0200, Gerd Hoffmann wrote: > Hi, > > > Hmm. Maybe it's still possible to salvage something by redefining the > > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it > > might still result in something usable. > > Also at least for the virtual machine use case this doesn't buy us much. > The

On Fri, Apr 07, 2017 at 10:29:00AM +0200, Gerd Hoffmann wrote: > Hi, > > > Hmm. Maybe it's still possible to salvage something by redefining the > > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it > > might still result in something usable. > > Also at least for the virtual machine use case this doesn't buy us much. > The

...a00 +nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 0000e800 nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 nouveau 0000:02:00.0: disp: 0878: 00000000 nouveau 0000:02:00.0: disp: 0880: 05000000 Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in 64MB case. Why? I get blank screen even with 64MB with video=1280x1024-8 kernel parameter. Console works with video=1280x1024-16 even with 32MB stolen memory. Conclusions: 8-bit support is broken and bpp reduction is weird. > Sounds like things are generally working, just the fbco...

...+nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 0000e800 > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 > nouveau 0000:02:00.0: disp: 0878: 00000000 > nouveau 0000:02:00.0: disp: 0880: 05000000 > > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in 64MB > case. Why? > > I get blank screen even with 64MB with video=1280x1024-8 kernel parameter. > Console works with video=1280x1024-16 even with 32MB stolen memory. > > Conclusions: 8-bit support is broken and bpp reduction is weird. OK, well that makes a *ton* of s...

...0 -> 0000e800 >> > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 >> > nouveau 0000:02:00.0: disp: 0878: 00000000 >> > nouveau 0000:02:00.0: disp: 0880: 05000000 >> > >> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in >> > 64MB case. Why? >> > >> > I get blank screen even with 64MB with video=1280x1024-8 kernel >> > parameter. Console works with video=1280x1024-16 even with 32MB stolen >> > memory. >> > >> > Conclusions: 8-bit support is...

...hose could be handled without the flag. But when mixed with any > other format the code would look a bit weird IMO. Well, there is a reason only the 32bpp formats are supported. With those you just adjust your color shifts and you are done. No need to actually byte-swap. In contrast handling 16bpp formats (5:6:5 or 5:5:5) with the non-native byte order is a PITA. The other reason of course is that this is the default format these days. So, do any "other formats" exist where the byteswapped variant is used in practice? Or can we just drop DRM_FORMAT_BIG_ENDIAN? > So my idea w...

...e was a module parameter which enables 24/32 > > bpp support and disables higher resolutions (due to cirrus hardware > > constrains). That parameter wasn't reimplemented. > > One slightly annoying aspect of this (well, initially of the patch to > clamp the default to 16bpp, but this too) is that we only have a way to > ask the driver which format it prefers, not which ones it supports at > all. For X's modesetting driver (and yes some of this is because X is > awful) this creates the following failure mode: > > 1: user sets up xorg.conf for depth 2...

Hi, i would like to play Half Life 1, its quite old and should run well on my hardware. This is a none steam version if i start it with wine version: 1.1.11 i get the error: Code: ChoosePixelFormat failed what i tried: running the desktop at 16bpp with software/opengl/d3d in hl1 no luck :( hl1 version: on the cd is a file called VERSION.TXT: Half-Life //Game Name 71176 //Product ID 1.1.0.8 //Version Number 9/24/2001 //Date

Adam Jackson (6): Remove a leftover from overlay support Fix xf86ModeBandwidth check Move device ID and memory sizing much earlier in setup G200SE: Only force 16bpp on low-memory cards Fix ChangeLog generation mga 1.4.10 Alan Coopersmith (2): Remove xorgconfig & xorgcfg from See Also list in man page Add README with pointers to mailing list, bugzilla & git repos Chris Ball (2): Build fix for EXA 3 Revert "Buil...

...s to get rid of a debug message that was lagging the navigation of the game. Anyway whenever I try to run Tribes in OpenGL I get a error saying that it cant change the display mode of the X server and to try and put X win that mode beforehand. Well I've tried it at 800x600 in both 15bpp and 16bpp. I never had the problem with Glide and Wine, tribes would just load right up and i could play. Output is attached below -------------------------------------------------------------- bash-2.04# wine Tribes.exe fixme:console:SetConsoleCtrlHandler (0x60a620,1) - no error checking or testing ye...

...ree disk space, then check your virtual memory settings." At that moment I had 39248 Kbyte free memory and 1.1Gbyte of free disk space. When I choose "Continue" I get nothing but blank screen. I tried managed/unmanaged, dga/nodga modes, 640x480 and other resolutions with 8bpp and 16bpp, but didn't success. Now I'm not know what to do further.... :-( System info (I don't which does matter): codeweavers-wine-20020411, XFree86-4.2.0, kernel-2.4.18, gnome-1.4, 256Mbyte RAM, AMD Duron 800 Mhz. Help me or I'll going crazy... ;-( Thanks in advance, SiX