| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
The enum and OptionInfoRec weren't removed in the initial patch
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
The NoAccel option is not valid for other chips.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Without kernel support and explicit knowledge about where in the ring the
last rendering operation for a specific pixmap was, we must synchronize with
any outstanding rendering before accessing a pixmap which does not have a
buffer object.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
The frame buffer only has a valid address between prepare_access and
finish_access calls, so remove all other attempts to compute an address from
the driver.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
We only need to get static offsets for objects when not running KMS,
otherwise the kernel will manage those as needed for us.
Binding objects is done in one of two ways. For GEM buffer objects, we use
dri_bo_pin. For GART allocated memory, we bind that to the GART.
|
|
GEM requires GTT space to map objects. Under KMS, the kernel driver has
already provided all available GTT space to GEM, so the X server need not do
anything.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
For non-DRM environments, the screen pixmap will be GART allocated memory
and not a libdrm buffer object and so uxa will only use devPrivate.ptr to
find the associated memory. Make sure devPrivate.ptr is set each time the
framebuffer is allocated so that uxa will be able to draw to it.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
KMS mode does not call I830AccelMethodInit as that does the user
modesetting initialization (yes, it was misnamed), but that means that the DRI option
was ignored. Create a new i830_check_dri_option function to do the option
detection, then remove that from I830AccelMethodInit, which is renamed
i830_user_modesetting_init to reflect what it actually does.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
This removes yet another 'debugging' option that hasn't seen real use in a
long time, and wasn't supported under KMS in any case.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
Noticed by: Michel Dänzer <michel@daenzer.net>
|
|
The overcommit of address space combined with these buffers hitting SW
fallbacks all the time means that we're probably better off telling the
application "no" instead of likely silently failing later.
Bug #22601.
|
|
The kernel ignores it if dd_major is -1, anyway.
|
|
Currently we implemented basic sdvo lvds function,
But except for sdvo lvds fixed mode, we can not switch
to other modes, otherwise display get black. The patch
intends to work for all modes whose HDisplay and VDisplay
are lower than fixed mode.
Signed-off-by: Ma Ling <ling.ma@intel.com>
|
|
The bigrequests limit isn't present in current X servers (tested using
textured video on a 965 with both image and window at 2048x2048 on a
1920x1200 display, and image at 2048x2048, window at 1024x1024).
Remove the artificial limit, enabling full-screen HD video when
rotated.
|
|
When not using DRI, the screen pixmap is not in a bo, and so the usual
enable/disable access functions don't adjust the pixmap devPrivate field,
leaving it to the frame buffer allocation code to assign this correctly.
During mode setting and fb resizing, FB access is disabled, and the
screen pixmap devPrivate is stashed away by xf86EnableDisableFBAccess,
to be restored when FB access is turned back on. This means that we have to
set the pixmap devPrivate.ptr (in case xf86EnableDisableFBAccess doesn't
do this), along with storing the address in the scrn->pixmapPrivate field.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
After failing to become DRM master, the X server dies attempting to close
the master fd during free:
(EE) intel(0): [drm] failed to set drm interface version.
(EE) intel(0): Failed to become DRM master.
(EE) intel(0): failed to get resources: Bad file descriptor
(EE) intel(0): Kernel modesetting setup failed
Backtrace:
0: X(xorg_backtrace+0x3b) [0x8133a3b]
1: X(xf86SigHandler+0x55) [0x80c7945]
2: [0xb805d400]
3: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b4bfcc]
4: X(xf86DeleteScreen+0x6b) [0x80d465b]
5: X(InitOutput+0x548) [0x80b0158]
6: X(main+0x1cb) [0x807220b]
7: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7d107a5]
8: X [0x8071881]
Saw signal 11. Server aborting.
ddxSigGiveUp: Closing log
ddxSigGiveUp: re-raising 11
Segmentation fault
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This DRI2 version does not support the old CreateBuffers/DestroyBuffers
interface anymore.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
The DRI2 interface was changed to support both old and new drivers in an
API/ABI compatible fashion. This change syncs the intel driver with the new
version of the DRI2 API.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
This file is not even referenced by any Makefile.am
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Don't make FBC count for memory allocation.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
When playing a movie that is clipped on its left and right edges the Xorg
server will SEGV sometimes. This is because the intel driver ignores the
clipping info when it copies the planes out of the XV data.
The check for the optimised copy was wrong to ignore the width required.
Which leads to too much data being copied by the memcpy. It the source buffer
happens to end exactly on a page boundary the server will SEGV.
As we reviewed the code we checked the calculation of src1, src2 and src3.
The patch includes additional comments to make it clear what the elements of
the calculation are.
This bug exists in git head and we also see it in 2.4.1.
Barry
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Since the scratch pixmap header will be re-used after allocation, we
need to clear its bo attachment when we stop using it, otherwise a later
user will use a bogus bo.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
Just moved the code, no other changes.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
To slightly clean up the implementation of i830_update_polyphase_coeffs,
introduce the two small helper functions i830_limit_coeff and
i830_store coeffs_in_overlay_regs.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Just moved the code ouf of line.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This is in the overlay path and therefore always true.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
- also ensure that the most significant byte is zero
- while I was looking at the code, add the Overlay suffix to
SetPortAttribute like in the textured case.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
overlay and textured video have the exact same QueryImageAttributes
function.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Bug #22107.
|
|
Bug #19578. We should set private intel_crtc state according
to current, as fail to do so pipe A needs active won't be taken
care of. Also make sure pipe swap operation always set during
VT switch.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
If i915 module has already been loaded and kms check is true,
it would be nice to load fbcon module too.
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
|
|
The only things we try to pin in KMS mode are the cursor objects and
front buffer, and those are taken care of by the kernel anyway, so we
shouldn't even bother trying to pin them (well, not entirely true,
XvMC tries to pin as well, but it needs work w/KMS anyway).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
This is what's expected by the server, and allows the EDID for example
to be exported in the KMS case.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
The KMS side was correct, but the UMS patch was broken. We need to use
the DVO timing block of the LFP data to get the timing, not the
fp_timing block.
Fixes fdo bug #22529.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
Makes it easier to see where things go wrong.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
This brings necessary change for IGDNG for texture video support
from 2D render code.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
This patch enables 2D composite on IGDNG. IGDNG requires
new compiled shader programs for Gen5 and some command changes.
The most notable is the layout of vertex element has changed,
but we tried to keep it as origin to not change shader programs.
Also vertex buffer state requires end address of vertex buffer
instead of origin max index.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Also check intel-gen4asm tool here for new -g option, which is
required to compile new programs.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
In KMS mode, the kernel takes care of this for us, so don't bother.
|
|
Useful for debugging.
|
|
Commit 1eec83a203c48822400742a1fb184b2cb52c62f7, which added the new
SwapbuffersWait option, didn't actually include the code which used it. So
add a test to DRI2's CopyRegion call, only emitting the scanline wait
command if the swapbuffers_wait option is set.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
These chips require physical address for XvMC surface, which
is not available in KMS case. Instead of crashing X, disable it now.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Otherwise we may end up returning a false positive if some other output & crtc
are on, but not the one in question, again leading to hangs.
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
