search for: 30bpp

On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote: > On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote: >> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: >> > In case anyone's curious about 30bpp framebuffer support, here's the >> > current status: >> > >> > Kernel: >> > >> > Ben and I have switched the code to using a 256-based LUT for Kepler+, >> > and I've also written a patch to cause the addfb ioctl to use the >> >...

On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote: > On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: > > In case anyone's curious about 30bpp framebuffer support, here's the > > current status: > > > > Kernel: > > > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > > and I've also written a patch to cause the addfb ioctl to use the > > proper format. You can pic...

On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: > In case anyone's curious about 30bpp framebuffer support, here's the > current status: > > Kernel: > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > and I've also written a patch to cause the addfb ioctl to use the > proper format. You can pick this up at: > > https://gi...

In case anyone's curious about 30bpp framebuffer support, here's the current status: Kernel: Ben and I have switched the code to using a 256-based LUT for Kepler+, and I've also written a patch to cause the addfb ioctl to use the proper format. You can pick this up at: https://github.com/skeggsb/linux/commits/linux-4.16 (no...

On 02/05/2018 12:50 AM, Ilia Mirkin wrote: > In case anyone's curious about 30bpp framebuffer support, here's the > current status: > > Kernel: > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > and I've also written a patch to cause the addfb ioctl to use the > proper format. You can pick this up at: > > https://gi...

Cc'ing mesa-dev, which was left out. On 03/05/2018 01:40 PM, Ilia Mirkin wrote: > On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner > <mario.kleiner.de at gmail.com> wrote: >> On 02/05/2018 12:50 AM, Ilia Mirkin wrote: >>> >>> In case anyone's curious about 30bpp framebuffer support, here's the >>> current status: >>> >>> Kernel: >>> >>> Ben and I have switched the code to using a 256-based LUT for Kepler+, >>> and I've also written a patch to cause the addfb ioctl to use the >>> proper...

Not clear what the depth % 8 was trying to protect against, but it was breaking 30bpp visuals with DRI3. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/nouveau_dri2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c index cbb7b2a..07b6022 100644 --- a/src/nouveau_dri2.c +++ b/src/nouveau_dri2.c @@ -1076...

On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner <mario.kleiner.de at gmail.com> wrote: > Cc'ing mesa-dev, which was left out. > > > On 03/05/2018 01:40 PM, Ilia Mirkin wrote: >> >> On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner >> <mario.kleiner.de at gmail.com> wrote: >>> Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs

On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner <mario.kleiner.de at gmail.com> wrote: > On 02/05/2018 12:50 AM, Ilia Mirkin wrote: >> >> In case anyone's curious about 30bpp framebuffer support, here's the >> current status: >> >> Kernel: >> >> Ben and I have switched the code to using a 256-based LUT for Kepler+, >> and I've also written a patch to cause the addfb ioctl to use the >> proper format. You can pick this up...

Unfortunately the ABI is a little annoying around almost requiring a 256-entry lut. While that is being worked out, allow proper mapping of colors in 30bpp framebuffers. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- If I bump the gamma size to 1024, then all existing software will start failing since the gamma set ioctl expects the size to match. But xf86-video-nouveau does not pull in the "real" gaamma size and just assum...

On Sun, Dec 31, 2017 at 2:23 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Not clear what the depth % 8 was trying to protect against, but it was > breaking 30bpp visuals with DRI3. Erm, actually switching to my test config which doesn't enable dri3 is what "fixed" things. DRI3 is still busted. Ignore this patch until that's properly figured out for 30bpp. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- >...

This is what was done prior to the big refactor in kernel 3.8, and what was done by xf86-video-nv. Experimentally, it seems like there's some sort of issue with the high-res lut to be used there. Tested on G92. This ends up mattering because fbcon/fbdev chooses the C8 fb format for low-vram systems, which can occur with some IGP-based configurations with little "stolen" vram.

...R flag to dmabuf export Huang Rui (1): amdgpu: add navi family id Ilia Mirkin (11): util: add C8 format, support it with SMPTE pattern util: fix MAKE_RGBA macro for 10bpp modes util: add gradient pattern util: add fp16 format support util: add cairo drawing for 30bpp formats when available modetest: don't pretend that atomic mode includes a format modetest: add an add_property_optional variant that does not print errors modetest: add C8 support to generate SMPTE pattern modetest: add the ability to specify fill patterns on the comman...

Not clear what the depth % 8 was trying to protect against, but it was breaking 30bpp visuals with DRI3. Add it in to ensure that bitsPerPixel % 8 is 0, since there is plenty of bpp/8 math in the driver. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/nouveau_dri2.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/nouveau_dri2.c b/src/...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Full log below, but most notably: - Better 30bpp handling - DP-MST hotplug support - DRI3/Present support in the presence of rotated RandR screens - Updates for various Xorg API changes - Autoconf cleanups Adam Jackson (1): modesetting: Validate the atom for enum properties Ilia Mirkin (10): man: remove reference to glamor under...

Hi, This is my work in documenting EVO. I did some RE to fill missing gaps. Best regards, Maxim Levitsky