| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fixed locally for af45482a52999b52bf41468c458808e30c100e35, but pushed
wrong commit.
(cherry picked from commit 62494407e529cfa68529b7267155a12d75418f21)
|
|
|
|
|
|
An additional 5 patches were proposed at:
http://wiki.x.org/wiki/Intel28Branch
|
|
The 965 docs note, and it's probably the case on 915 as well, that the
2x2 subspans are read as a unit, even if the bottom row isn't used. If
the address in that bottom row extended beyond the end of the GTT, a
fault could occur.
Thanks to Chris Wilson for pointing out the problem.
(cherry picked from commit 465a4ab416b2e5ad53b96702720331a44fffa2fe)
|
|
We only set up one sampler, because all of our sampling is the same. By
using a non-zero index for the other two samplers, we'd dereference (likely)
zeroed data, resulting in using NEAREST filtering. This was a regression in
40671132cb3732728703c6444f4577467fa9223f which incidentally switched from
having 6 samplers to 1.
Bug #22895, #19856
(cherry picked from commit 79b6851148574419389ac8055b0c31b8bdac3ab3)
|
|
Now the DVO timing in LVDS data entry is obtained by using the
following step:
a. get the entry size for every LVDS panel data
b. Get the LVDS fp entry for the preferred panel type
c. get the DVO timing by using entry->dvo_timing
In our driver the entry->dvo_timing is related with the size of
lvds_fp_timing. For example: the size is 46.
But it seems that the size of lvds_fp_timing varies on the differnt
platform. In such case we will get the incorrect DVO timing because of
the incorrect DVO offset in LVDS panel data entry.
Calculate the DVO timing offset in LVDS data entry to get the DVO timing
a. get the DVO timing offset in the LVDS fp data entry by using the
pointer definition in LVDS data ptr
b. get the LVDS data entry
c. get the DVO timing by adding the DVO timing offset to data entry
https://bugs.freedesktop.org/show_bug.cgi?id=22787
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
(cherry picked from commit af45482a52999b52bf41468c458808e30c100e35)
|
|
This should save significant amounts of memory for glyph and other small
pixmap storage.
Bug #21387
(cherry picked from commit 6b7728491c3b771bcba2c7ffd75330c0a0b37f44)
|
|
This synchronizes the X EDID data with the kernel EDID data each time the
kernel data may have changed. Otherwise, X ends up stuck with the first EDID
data it sees, failing to accomodate to different monitors.
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 6f3fc6b20f3daedab02e31f49678d4d2ff0fa7a3)
|
|
This is the version number for release candidate 1 of 2.8.1.
|
|
Just a couple of cherry-picked fixes.
|
|
(plus fix)
Original alignment patch
(cherry picked from commit 222b52ef16895823fbf3a0fc0be4eb23b930ed1b)
with subsequent "Fix math in the tiling alignment fix" squashed
(cherry picked from commit e8f0763d405a8152c74c28792c52fe12c1d41dd5)
|
|
This removes the explicit transform disabling code in drm_set_mode_major.
Without a fixed X server, transforms will still be broken, but even a fixed
X server can't work around this driver bug.
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 8084f76d86f048ca5b82da089fffa9665dbbcdd5)
|
|
|
|
Many thanks to Gordon for his notes from http://intellinuxgraphics.org/2009Q2.html
|
|
|
|
The two shared i830_composite.c, so giving i830 atomic batch support
triggered anger about starting i830's atomic area while in i915's atomic
area. Instead, split the emit-a-primitive stuff from the state emission.
|
|
Bug #22483.
|
|
scrn->fbOffset may be changed when binding objects to the aperture during
server initialization or VT enter. This was accidentally removed when the
NoAlloc option was eliminated.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
|
|
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>
|
