search for: bitsperpixel

Pre-nv50 has all sorts of funny requirements for non-copy alu operations, and will bail out of solid fills left and right. Account for that case and fall back to the memset. Reported-by: Andrew Randrianasulu <randrianasulu at gmail.com> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/drmmode_display.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)

...pNv = NVPTR(pScrn); + + if (!pNv->exa_driver_pixmaps) + NVSync(xf86Screens[pScreen->myNum]); } static Bool @@ -351,17 +355,16 @@ nouveau_exa_modify_pixmap_header(PixmapPtr ppix, int width, int height, if (!nvpix->bo && nvpix->size) { uint32_t cpp = ppix->drawable.bitsPerPixel >> 3; - /* At some point we should just keep 1bpp pixmaps in sysram */ uint32_t flags = NOUVEAU_BO_VRAM; int ret; if (pNv->Architecture >= NV_ARCH_50 && cpp) { - uint32_t aw = (width + 7) & ~7; - uint32_t ah = (height + 7) & ~7; + uint32_t ah = (height...

Couple of patches to fix an overflow, optimize a bit and support bigger resolutions using Windows 8.

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/nouveau_dri2.c index cbb7b2a..ac0ca09 100644 --- a/src/no...

...eletions(-) diff --git a/src/nv04_exa.c b/src/nv04_exa.c index 132c9d5..7384cbc 100644 --- a/src/nv04_exa.c +++ b/src/nv04_exa.c @@ -197,16 +197,9 @@ NV04EXAPrepareCopy(PixmapPtr pSrcPixmap, PixmapPtr pDstPixmap, int dx, int dy, return FALSE; planemask |= ~0 << pDstPixmap->drawable.bitsPerPixel; - if (planemask != ~0 || alu != GXcopy) { - if (pDstPixmap->drawable.bitsPerPixel == 32) - return FALSE; - BEGIN_RING(chan, blit, NV04_IMAGE_BLIT_OPERATION, 1); - OUT_RING (chan, 1); /* ROP_AND */ - NV04EXASetROP(pScrn, alu, planemask); - } else { - BEGIN_RING(chan, blit, NV04_IMAGE_BLI...

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,7 +1076,7 @@

Two "updated" patches, according to Michel Daenzers review. See separate e-mail for details. 01/10: Replaces original 01/09 -- Same code, updated commit message. 10/10: Just for demonstration, not for application to ddx.

...earching for matching VESA mode(s): Mode: 160 (0x0) ModeAttributes: 0x0 WinAAttributes: 0x0 WinBAttributes: 0x0 WinGranularity: 0 WinSize: 0 WinASegment: 0x0 WinBSegment: 0x0 WinFuncPtr: 0x0 BytesPerScanline: 0 XResolution: 0 YResolution: 0 XCharSize: 0 YCharSize: 0 NumberOfPlanes: 0 BitsPerPixel: 0 NumberOfBanks: 0 MemoryModel: 0 BankSize: 0 NumberOfImages: 0 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0x0 LinBytesPerScanLine: 0 BnkNumb...

...blem on Xilinx. >>> >>> Great. Thanks for testing. >>> >>>> >>>>> ioctl is unsuited for anything but the simple RGB formats. The bpp >>>> >>>> It's a bit difficult 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 >&gt...

.../nv50_xv.c index b2541b9..ba01c99 100644 --- a/src/nv50_xv.c +++ b/src/nv50_xv.c @@ -91,8 +91,9 @@ nv50_xv_image_put(ScrnInfoPtr pScrn, BEGIN_NV04(push, NV50_3D(RT_ADDRESS_HIGH(0)), 5); PUSH_DATA (push, dst->offset >> 32); PUSH_DATA (push, dst->offset); - switch (ppix->drawable.bitsPerPixel) { + switch (ppix->drawable.depth) { case 32: PUSH_DATA (push, NV50_SURFACE_FORMAT_BGRA8_UNORM); break; + case 30: PUSH_DATA (push, NV50_SURFACE_FORMAT_RGB10_A2_UNORM); break; case 24: PUSH_DATA (push, NV50_SURFACE_FORMAT_BGRX8_UNORM); break; case 16: PUSH_DATA (push, NV50_SURFACE_FORMAT_B...

...ot.ini - Notepad"^M @PJL SET OUTBINPROCESS =1 ^M @PJL SET RET=ON^M @PJL SET DUPLEX=ON^M @PJL SET BINDING=LONGEDGE^M @PJL SET ECONOMODE=OFF^M @PJL SET OUTBIN=UPPER^M @PJL SET FINISH=NONE^M @PJL SET PAGEPROTECT=AUTO^M @PJL SET PAPER=LETTER^M @PJL SET HOLD=OFF^M @PJL SET RESOLUTION=600^M @PJL SET BITSPERPIXEL=2^M @PJL SET EDGETOEDGE=NO^M @PJL ENTER LANGUAGE=PCLXL^M ) HP-PCL XL;2;0;Comment Copyright Hewlett-Packard Company 1989-1998. Version 4.2.1.8 <snip> ---------------------------------------------------------------------------------------------- Miles Purdy System Manager Farm Income Programs...

...ched >>> fixes the problem on Xilinx. >> >> Great. Thanks for testing. >> >>> >>>> ioctl is unsuited for anything but the simple RGB formats. The bpp >>> >>> It's a bit difficult 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), wh...

...nd if we say that bpp==12 means NV12, it will be a >> problem for all other cases where bpp==12 makes sense. > > I feel I still don't quite understand. Can't we define and document > CREATE_DUMB like this: > > If (bpp < 8 || is_power_of_two(bpp)) > ????bpp means bitsperpixel > ????pitch is args->width * args->bpp / 8, aligned up to > driver-specific-align > else > ????bpp is a legacy parameter, and we deal with it case by case. > ????list the cases and what they mean > > And describe that when allocating subsampled buffers, the caller must...

...+ return FALSE; + active_crtc_count++; + } } return ((DRI2CanFlip(draw) && pNv->has_pageflip)) && dst_pix->drawable.width == src_pix->drawable.width && dst_pix->drawable.height == src_pix->drawable.height && dst_pix->drawable.bitsPerPixel == src_pix->drawable.bitsPerPixel && - dst_pix->devKind == src_pix->devKind; + dst_pix->devKind == src_pix->devKind && + active_crtc_count; } static Bool @@ -475,7 +479,7 @@ dri2_page_flip(DrawablePtr draw, PixmapPtr back, void *priv, int head = drmmode_crtc...

...>HWCursor = TRUE; @@ -887,8 +1021,8 @@ NVPreInit(ScrnInfoPtr pScrn, int flags) xf86DrvMsg(pScrn->scrnIndex, from, "Swap limit set to %d [Max allowed %d]%s\n", pNv->swap_limit, pNv->max_swap_limit, reason); - ret = drmmode_pre_init(pScrn, pNv->dev->fd, pScrn->bitsPerPixel >> 3); - if (ret == FALSE) + if (!xwl_screen && + !drmmode_pre_init(pScrn, pNv->dev->fd, pScrn->bitsPerPixel >> 3)) NVPreInitFail("Kernel modesetting failed to initialize\n"); /* @@ -1267,6 +1401,9 @@ NVScreenInit(int scrnIndex, ScreenPtr pScreen, int...

Hi, Please find attached the patches which I currently use on my desktop machine for dual head with the randr branch to fix the issues which I found. They may help others as well but may e.g. also disable the Xv blitter which might be working for some (but didn't on my card) - more information is found in the text comments in the patches. I have to hurry so this is short, will be back.

A short series of compiler visibility warning fixes that I prepared whilst trialing improvements to xf86-video-nouveau's use of the core xorg-server utility macros. Rhys Kidd (4): wfb: Remove declaration for undefined function nouveau_wfb_init() dri2: Mark local create/destroy buffer and copy region functions as static xv: Mark local NVSetupTexturedVideo function as static

...TE_DUMB > > I had missed the discussion, and, indeed, the patch you attached fixes > the problem on Xilinx. Great. Thanks for testing. > >> ioctl is unsuited for anything but the simple RGB formats. The bpp > > It's a bit difficult 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...

...discussion, and, indeed, the patch you attached fixes >> the problem on Xilinx. > > Great. Thanks for testing. > >> >>> ioctl is unsuited for anything but the simple RGB formats. The bpp >> >> It's a bit difficult 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 se...

...think it resolves all the points you have. The current CREATE_DUMB I had missed the discussion, and, indeed, the patch you attached fixes the problem on Xilinx. > ioctl is unsuited for anything but the simple RGB formats. The bpp It's a bit difficult 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. So, I'm all for a new ioctl, but I don't right away see why the current ioctl couldn't be used. Which makes me wonder abo...