Re: Xvfb and number of bytes per pixel

2020-09-10 Thread Adam Jackson 
On Wed, 2020-09-09 at 13:28 +0200, Marcin K wrote:
> Hello,
> I'm grabbing frames from Xvfb to use them as an opengl texture. I've
> noticed that there are 4 bytes per pixel, that suggest that there's
> an alpha channel, or something else. Is it possible to force Xvfb to
> store only RGB values in the shared memory?

Not without hacking the code, no. There's some code in the shadow
framebuffer logic that will downconvert from 32bpp to 24bpp, but it's
meant for super-low-end cards like the Matrox G200SE or Cirrus Logic
GD-5446 that really only have depth 24 at 24bpp. You could hook it up
to Xvfb, but you'd save no memory or performance to do so, since (in
xserver 1.20 and later) the server can't render directly to 24bpp, so
you'd be drawing to a 32bpp surface and then copying from that to
24bpp.

At which point, since basically no OpenGL-capable GPU since like the
Intel i810 actually has an RGB24 texture format in hardware, you'd
convert _back_ to 32bpp when you upload the texture, and that
conversion would also probably be in software.

You're almost certainly better off using a 32bpp XRGB texture in the
first place.

- ajax

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: no screens detected

2020-09-10 Thread Adam Jackson 
On Wed, 2020-09-09 at 16:56 +, Paul Kagan wrote:
> What do I do to get this to work?
>  
> x.org.log:
>  
> https://bsd.to/T3hR

The relevant bits of the log here are:

[ 53814.484] (--) PCI:*(0@0:2:0) 1013:00b8:1af4:1100 rev 0, Mem @ 
0xfc00/33554432, 0xfebd/4096, BIOS @ 0x/65536

This says your "video card" is the kind of Cirrus Logic GD-5446 that
qemu happens to have an emulator for. Which was not a great card even
when it was new, which was 1995. Then:

[ 53814.487] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so
[ 53814.487] (II) Module vesa: vendor="X.Org Foundation"
[ 53814.487] compiled for 1.20.8, module version = 2.4.0

Version 2.4.0 of the vesa driver is fairly old, but there isn't a new
version released yet. That's my fault, and here it would have saved you
some pain, because there's a bugfix since 2.4 that avoids the next
problem:

[ 53814.496] (EE) VESA(0): Specified fbbpp (24) is not a permitted value

The vesa driver tries to use a depth-24 framebuffer if possible.
However, the pathetic cirrus card that qemu emulates only supports
depth 24 at 24 bits per pixel, instead of the much more common and
performant 32 bits per pixel. Starting with xserver 1.20 the software
renderer no longer supports drawing to a 24bpp framebuffer, so when
vesa says "please use 24bpp it's all I have" the server says "nope" and
you crash.

I'll push out a new vesa driver release, since the current code in git
has a fix for this situation where it will use 16bpp instead. But I
strongly suggest you use literally any other emulated video card, and
not wait for the new driver release, because - again - the cirrus card
being emulated here is Not Good. If you're using qemu directly, saying
'-vga std' instead of cirrus will get you a much nicer basic graphics
experience than '-vga cirrus'. If you're using virt-manager or similar
you can configure this through the UI.

- ajax

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Xvfb and number of bytes per pixel

2020-09-10 Thread Marcin K 
Thank you for explanation.
That was my deepest fear. The main issue is that I'm copying the image data
real-time, and in my case, on 4* UWXGA display, this one byte means 9MB
less data per frame.


czw., 10 wrz 2020 o 23:32 Adam Jackson  napisał(a):

> On Wed, 2020-09-09 at 13:28 +0200, Marcin K wrote:
> > Hello,
> > I'm grabbing frames from Xvfb to use them as an opengl texture. I've
> > noticed that there are 4 bytes per pixel, that suggest that there's
> > an alpha channel, or something else. Is it possible to force Xvfb to
> > store only RGB values in the shared memory?
>
> Not without hacking the code, no. There's some code in the shadow
> framebuffer logic that will downconvert from 32bpp to 24bpp, but it's
> meant for super-low-end cards like the Matrox G200SE or Cirrus Logic
> GD-5446 that really only have depth 24 at 24bpp. You could hook it up
> to Xvfb, but you'd save no memory or performance to do so, since (in
> xserver 1.20 and later) the server can't render directly to 24bpp, so
> you'd be drawing to a 32bpp surface and then copying from that to
> 24bpp.
>
> At which point, since basically no OpenGL-capable GPU since like the
> Intel i810 actually has an RGB24 texture format in hardware, you'd
> convert _back_ to 32bpp when you upload the texture, and that
> conversion would also probably be in software.
>
> You're almost certainly better off using a 32bpp XRGB texture in the
> first place.
>
> - ajax
>
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[ANNOUNCE] xf86-video-vesa 2.5.0

2020-09-10 Thread Adam Jackson 
This release rolls up a few minor bug fixes since 2.4.0. We now refuse
to run on machines with UEFI firmware (on Linux only, patches welcome
for other OSes) since it won't work in the general case and you
probably have a kernel framebuffer driver running already. We also only
attempt to use 24bpp if the alternative would be pseudocolor, but note
that since xserver 1.20 24bpp will not work at all. If you'd like to
fix that case, please note that it is filed as issue #4:

https://gitlab.freedesktop.org/xorg/driver/xf86-video-vesa/-/issues/4

We also notice several cases of running on emulated GPUs, in which case
the shadow framebuffer is disabled by default to improve performance by
reducing the number of copies.

All users are recommended to upgrade, ideally to a better video card
and/or driver.

Full changelog:

Adam Jackson (5):
  Newline-terminate a few error messages
  Refuse to run on UEFI machines
  Try harder to avoid 24bpp
  Disable shadow by default on known-virtual GPUs
  vesa 2.5.0

Alan Coopersmith (2):
  Update README for gitlab migration
  Update configure.ac bug URL for gitlab migration

Benjamin Tissoires (1):
  Refuse to run on UEFI machines running older kernels

git tag: xf86-video-vesa-2.5.0

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.5.0.tar.bz2
MD5:  e7cf9705b3a60365e5c251a604bc72e9  xf86-video-vesa-2.5.0.tar.bz2
SHA1: 6b604c9284fe004723a59651ae2628b2b7e63b1e  xf86-video-vesa-2.5.0.tar.bz2
SHA256: 1f1624f3c73906801ad1bc98335a2cb5676a7a4d18e5374d9a1d18464e54c659  
xf86-video-vesa-2.5.0.tar.bz2
SHA512: 
36fd921f54f33eb25966b5f9ea1e1b3e9009965c012c8b9c676686b472111719921b80cf62dafc746058878253e21f0ef341a2ff2d650df22ca1e35e81716a8b
  xf86-video-vesa-2.5.0.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.5.0.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.5.0.tar.gz
MD5:  1cc6d82b149d3c2cf900e7771e154e1a  xf86-video-vesa-2.5.0.tar.gz
SHA1: 62ae49bf376c8b0652ddf320bb0f1c856dd0d56b  xf86-video-vesa-2.5.0.tar.gz
SHA256: be10771dbfdec9e8c4f1b56653b0e6b05b3e5f79c26507e3184ad27b4f00c09d  
xf86-video-vesa-2.5.0.tar.gz
SHA512: 
446344bd7fb6f1f39561b5be1c7eaf95a8cb9804c8d292c4f899bfe2099c68d2480642205d8ba5338f7b7dda2830c0c5a9383973fd58a915611b78b15cc553c9
  xf86-video-vesa-2.5.0.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.5.0.tar.gz.sig

- ajax

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

no screens detected

2020-09-10 Thread Paul Kagan 
What do I do to get this to work?

x.org.log:

https://bsd.to/T3hR

Thank you…


Provenance : Courrier pour 
Windows 10

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[ANNOUNCE] xf86-video-vesa 2.5.0

2020-09-10 Thread Adam Jackson 
This release rolls up a few minor bug fixes since 2.4.0. We now refuse
to run on machines with UEFI firmware (on Linux only, patches welcome
for other OSes) since it won't work in the general case and you
probably have a kernel framebuffer driver running already. We also only
attempt to use 24bpp if the alternative would be pseudocolor, but note
that since xserver 1.20 24bpp will not work at all. If you'd like to
fix that case, please note that it is filed as issue #4:

https://gitlab.freedesktop.org/xorg/driver/xf86-video-vesa/-/issues/4

We also notice several cases of running on emulated GPUs, in which case
the shadow framebuffer is disabled by default to improve performance by
reducing the number of copies.

All users are recommended to upgrade, ideally to a better video card
and/or driver.

Full changelog:

Adam Jackson (5):
  Newline-terminate a few error messages
  Refuse to run on UEFI machines
  Try harder to avoid 24bpp
  Disable shadow by default on known-virtual GPUs
  vesa 2.5.0

Alan Coopersmith (2):
  Update README for gitlab migration
  Update configure.ac bug URL for gitlab migration

Benjamin Tissoires (1):
  Refuse to run on UEFI machines running older kernels

git tag: xf86-video-vesa-2.5.0

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.5.0.tar.bz2
MD5:  e7cf9705b3a60365e5c251a604bc72e9  xf86-video-vesa-2.5.0.tar.bz2
SHA1: 6b604c9284fe004723a59651ae2628b2b7e63b1e  xf86-video-vesa-2.5.0.tar.bz2
SHA256: 1f1624f3c73906801ad1bc98335a2cb5676a7a4d18e5374d9a1d18464e54c659  
xf86-video-vesa-2.5.0.tar.bz2
SHA512: 
36fd921f54f33eb25966b5f9ea1e1b3e9009965c012c8b9c676686b472111719921b80cf62dafc746058878253e21f0ef341a2ff2d650df22ca1e35e81716a8b
  xf86-video-vesa-2.5.0.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.5.0.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.5.0.tar.gz
MD5:  1cc6d82b149d3c2cf900e7771e154e1a  xf86-video-vesa-2.5.0.tar.gz
SHA1: 62ae49bf376c8b0652ddf320bb0f1c856dd0d56b  xf86-video-vesa-2.5.0.tar.gz
SHA256: be10771dbfdec9e8c4f1b56653b0e6b05b3e5f79c26507e3184ad27b4f00c09d  
xf86-video-vesa-2.5.0.tar.gz
SHA512: 
446344bd7fb6f1f39561b5be1c7eaf95a8cb9804c8d292c4f899bfe2099c68d2480642205d8ba5338f7b7dda2830c0c5a9383973fd58a915611b78b15cc553c9
  xf86-video-vesa-2.5.0.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.5.0.tar.gz.sig

- ajax

___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce