| Age | Commit message (Collapse) | Author |
|---|
|
On 855, letting crtc_mode_set enable the plane and pipe will occasionally
hang the chip. Instead, wait for crtc_enable to light things up. For 9xx,
leave things alone.
|
|
|
|
This lights up my monitor VGA-1 - it doesn't look the best though
|
|
|
|
ifndef."
This reverts commit c2b130354aecffbeb2a2d23c7371461feaf5766a.
Sadly, a non-working DRM_IOCTL_I915_FLIP already existed.
|
|
|
|
Now, all 3D pipeline consumers in the driver just call
IntelEmitInvariantState(), which handles basic state setup, the caching of that
state setup, and notifying DRI clients. This also removes a mistaken idle
wait in the Render code which was papering over the brokenness in the context
switching.
|
|
|
|
This is already fixed in the definition in the 3d driver.
|
|
- The screen dimensions were used for the clipping despite drawing being done
to any pixmap, not necessarily the screen.
- One piece of state setup was not documented anywhere, and isn't used in other
3d hardware paths that also work.
- A 3DSTATE_MODES_1 command (830-class only) was issued even though it no
longer exists.
|
|
The 24-bit frame and pixel counters were not described in detail and
will be useful for DRM.
|
|
Which have to use gfx vm offset fot setup overlay regs.
|
|
These chipsets require that the hardware status page be referenced by an offset
in the GTT rather than a physical memory address, so the X Server allocates it
rather than the DRM.
|
|
|
|
|
|
Ok, so moving video from pipe A to pipe B still requires that pipe A be
active during the transition. Instead of trying to be fancy, just ensure
that pipe A is running on each transition to pipe B.
|
|
As crtcs are disabled and enabled, make sure the automatic crtc selection
mechanism drives overlay configuration at each request to display an image.
|
|
|
|
|
|
|
|
Use scrn's virtual size is not correct in rotation rendering.
This fixes initial rotation problem on i965.
|
|
|
|
Apparently some BIOSes will program a small mode with large blanking instead of
using the pannel fitter.
|
|
|
|
I don't understand it, but just like the video overlay, if Pipe A is not
running, Pipe B will not turn the first time it is activated. This
patch restructures the code used for the video overlay to share it
with the crtc commit function.
|
|
debian-experimental
|
|
By clipping to the crtc ahead of time, xf86XVClipVideoHelper will
correctly clip to the bounds of the crtc, eliminating the need for any
custom crtc clipping.
Also, replace the broken xf86XVFillKeyHelper with a private version that
doesn't end up stuck with the wrong clip list when the root window changes
size.
|
|
The overlay on the i830 appears to be clocked by Pipe A when being enabled.
If pipe A is not running, it will freeze the overlay and blank the screen.
Setting a random mode on the Pipe and turning it on fixes this problem
nicely.
|
|
|
|
Create separate CRTC selection function, use ints instead of floats for
coverage measurement. Remove pipe stalls waiting for overlay update.
|
|
No need to block for the overlay; just use the idle buffer. This will
always work because the buffer switch occurs at vblank time, so there is
always plenty of time to get the next buffer contents in place before it
starts getting scanned to the screen.
|
|
Yes, I can't stand it anymore. it's a huge patch, but
git-diff -w shows no changes.
|
|
Create separate on/continue/off functions for overlay.
Manage overlayOn boolean within those functions.
Eliminate redundant management code in other routines.
|
|
This makes the overlay work on i830 with the modesetting driver. I don't
know why the pre-modesetting driver worked without this, but it did.
A more 'correct' fix would be welcome, but this does seem to do the trick.
|
|
By default, select crtc based on which one covers more of the video output.
pipe property can be used to override selection when both have partial
coverage.
|
|
Replace pipe indices with crtc indices and store references to the xf86Crtc
objects in the video private structure.
|
|
When the hardware locks up, dump the pending commands in the ring for
analysis.
|
|
|
|
|
|
That notify mesa rendering is smashing the state, and check last 3d
operation to do sync after we're swapped in or others.
|
|
Use proper unsigned type for timer variables, and try to dump 965G state.
|
|
|
|
Move clone/crtc config into each output where it's easier to understand (no
need for a switch statement in I830PrepareOutputs. Also, split DVO into
three sub-types (TMDS, LVDS, TVOUT) as those have different cloning
abilities.
|
|
Using BIOS source code as a guide, set up the panel fitter on the ivch. This
involves setting the pipe to the panel fixed mode, the DVO to the source
size and assigning vertical and horizontal scaling factors in the ivch
itself.
|
|
The DVO module interface reflected most of the xf86Output API to the
underlying functions; finish that work given the changes that have since
occurred in the xf86Output API.
Move the LVDS-specific code into the IVCH module and make that work on the
Thinkpad X30 (an i830-based laptop). Panel scaling does not work yet.
|
|
Add-in modules have per-module data in the BIOS which contains configuration
information which cannot be entirely discovered.
|
|
Chips newer than the i830 can force the border color for the active period
of the screen, allowing the load detection to easily see the right data. In
addition, newer chips appear to have more sensible load detection hardware
which either ignores inactive periods on the screen or performs some
longer-term averaging. The i830 appears to provide unfiltered samples of the
detected load.
For the i830, then, emit a border at the bottom of the screen and, for load
detection, simply turn it purple and wait for the current line to be within
the border. Sample an entire scanline, counting the number of times the load
detection sees a monitor. In my testing, the presence of a monitor will
cause the detection to succeed every time, while the absense will cause it
to fail about 75% of the time. The code here, checks for presence at least
75% of the time, which should be adequate.
Also, as the new mode configuration code has already taken care to enable
the CRT output, eliminate much of the load detection code which is simply
duplicating functionality from the general mode setting code. This should
result in faster load detection as this code will now run in no more than
one frame time. It does burn the CPU the whole time though, polling the
displayed scanline register.
|
|
|
|
|
|
Reported by: Haihao Xiang <haihao.xiang@intel.com>
|
