search for: xrgb1555

...unsuited? bitsperpixel, >> width and height do give an exact pitch and size, do they not? It does >> require the userspace to handle the subsampling and planes, though, so >> far from perfect. > > The bpp value sets the number of bits per pixel; except for bpp==15 > (XRGB1555), where it sets the color depth. OR bpp is the color depth; > except for bpp==32 (XRGB8888), where it is the number of bits per pixel. > It's therefore best to interpret it like a color-mode enum. Ah, right... That's horrible =). And I assume it's not really possible to define...

...bitsperpixel, width and height do give an exact pitch and size, do >>> they not? It does require the userspace to handle the subsampling >>> and planes, though, so far from perfect. >> >> The bpp value sets the number of bits per pixel; except for bpp==15 >> (XRGB1555), where it sets the color depth. OR bpp is the color depth; >> except for bpp==32 (XRGB8888), where it is the number of bits per >> pixel. It's therefore best to interpret it like a color-mode enum. > > Ah, right... That's horrible =). > > And I assume it's not...

...t to use, but is it really unsuited? bitsperpixel, > width and height do give an exact pitch and size, do they not? It does > require the userspace to handle the subsampling and planes, though, so > far from perfect. The bpp value sets the number of bits per pixel; except for bpp==15 (XRGB1555), where it sets the color depth. OR bpp is the color depth; except for bpp==32 (XRGB8888), where it is the number of bits per pixel. It's therefore best to interpret it like a color-mode enum. > > So, I'm all for a new ioctl, but I don't right away see why the > current ioc...

...mine target endianness using meson util: fix 32 bpp patterns on big-endian util: fix 16 bpp patterns on big-endian util: add missing big-endian RGB16 frame buffer formats modetest: add support for parsing big-endian formats util: add test pattern support for big-endian XRGB1555/RGB565 util: fix pwetty on big-endian util: add pwetty support for big-endian RGB565 modetest: add support for big-endian XRGB1555/RGB565 Jonas Karlman (1): modetest: add support for DRM_FORMAT_NV{15,20,30} Neil Armstrong (1): modetest: switch usage to proper options...

...and height do give an exact pitch and size, do >>>> they not? It does require the userspace to handle the subsampling >>>> and planes, though, so far from perfect. >>> >>> The bpp value sets the number of bits per pixel; except for bpp==15 >>> (XRGB1555), where it sets the color depth. OR bpp is the color depth; >>> except for bpp==32 (XRGB8888), where it is the number of bits per >>> pixel. It's therefore best to interpret it like a color-mode enum. >> >> Ah, right... That's horrible =). >> >> A...

Hi list, my media center PC is freshly installed with Debian 10.2 "Buster". It doesn't support Geforce 6800 GT (NV40) boards through the nvidia nor the nvidia-legacy drivers any longer. The legacy drivers worked up until Debian 9 "Stretch", but no longer. I know that the hardware works because I can boot SystemRescueCD from CD and get a flawless desktop presentation on

Hi, On 15/01/2025 12:26, Thomas Zimmermann wrote: > Hi > > > Am 15.01.25 um 11:13 schrieb Tomi Valkeinen: >> Hi! >> >> On 09/01/2025 16:57, Thomas Zimmermann wrote: >>> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and >>> buffer size. Align the pitch according to hardware requirements. >>> >>> Signed-off-by:

This came out of some debugging I was doing to figure out how BE mode works on this hardware. Among other things, it came out that we're not exposing 16-bpp mode support and that the ARGB8888 mode that we do expose is broken. Also the overlay logic was pretty broken, I must have only tested with very "normal" overlay buffer sizes with modetest before. That said, this code has only

This was all kicked off by me figuring out how the PPC byteswap thing worked. In the end, we're keeping the implicit byteswap based on architecture, but also expose the correctly supported formats, and fix some overlay details. Overlay framebuffers have various funky requirements that should be enforced at framebuffer creation time (these are set apart by their YUV formats). Further, I

This came out of some debugging I was doing to figure out how BE mode works on this hardware. Among other things, it came out that we're not exposing 16-bpp mode support and that the ARGB8888 mode that we do expose is broken. Also the overlay logic was pretty broken, I must have only tested with very "normal" overlay buffer sizes with modetest before. That said, this code has only