| Age | Commit message (Collapse) | Author |
|---|
|
Some fields had snuck into the drm_output structure. Put them back and
fill in more stuff from the EDID block.
|
|
TV out needs to do load detection, which means we have to find an
available pipe to use for the detection. Port over the pipe reservation
code for this purpose.
|
|
This patch ties outputs, output properties and hotplug events into the
DRM core. Each output has a corresponding directory under the primary
DRM device (usually card0) containing dpms, edid, modes, and connection
status files.
New hotplug change events occur when outputs are added or hotplug events
are detected.
|
|
Allow mode to be set with fb_id set to -1, meaning set
the mode with the current fb (if we have one bound).
Allow intelfb to hook back up it's fb if modesetting
clears it (maybe temporary).
Move any crtc->fb related register changes to set_base
in intel_fb.
General intelfb cleanups.
|
|
|
|
|
|
Ported from xf86-video-intel. Still need to tie in TV modes somehow, though
preferably w/o using the properties mechanism.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This also starts to add blob property support.
someone needs to check this work for other things like ppc/x86 alignment diffs
|
|
|
|
This allow the user to retrieve a list of properties for an output.
Properties can either be 32-bit values or an enum with an associated name.
Range properties are to be supported.
This API is probably not all correct, I may make properties part of the general
resource get when I think about it some more.
So basically you can create properties and attached them to whatever outputs you want,
so it should be possible to create some generics and just attach them to every output.
|
|
|
|
|
|
this stops usermode from getting a mode in the crtc it can't make sense off.
|
|
Userspace expects a 1 based enum for connection status so fix up the kernel
definition.
|
|
|
|
This way driver can get_edid in output status detection
(using all workaround which are in get_edid) and then provide
this edid data in get_mode callback of output.
|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_bo.c
linux-core/drm_drv.c
linux-core/drm_objects.h
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
Mostly removing typedefs that snuck into the modesetting code and
updating to the latest TTM APIs. As of today, the i915 driver builds,
but there are likely to be problems, so debugging and bugfixes will
come next.
|
|
|
|
into origin/modesetting-101
Conflicts:
linux-core/drm_crtc.c - reconcile with locking changes
|
|
held across any operations that modify mode lists, crtc config, output
config, etc. It should be taken at high level entry points (currently just
initial config and user IOCTL).
Seems to work ok on my system, but needs more testing (with lockdep) and
review from some fresh eyes.
|
|
it a chance to allocate the memory from whichever buffer it wants to.
|
|
Change from DIRECTCOLOR to TRUECOLOR, and enable
support for PSEUDOCOLOR. DIRECTCOLOR support needs more work.
Add the ability to change the mode on the fbdev device.
Support depth 8, 15, 16 and 24 (and 32).
Add a /dev/fbX device per CRTC, but there's some code which
doesn't allocate the fbX device unless the output is actually
enabled. Read the code on this as it impacts the fbcon map flags.
Pick CRTC's based on the available outputs. More work could
be done here to match modes, so cloning could be achieved on
outputs. This fits more inline with what the X code does.
|
|
This allows userspace to specify modes and add them to the modesetting
system and attach modes to outputs
|
|
The mode list sets all the output modes to UNVERIFIED, then probes a new list,
If a mode is on the new list and not on the old, it adds it to the old,
if a mode is on the new list and old, it just updates the status to the new
mode status.
If a mode is on the old list and not on the new, prune invalid modes should
remove all UNVERIFIED modes
|
|
(we can just recombine them now).
|
|
monitor limits, etc.
|
|
|
|
drm_mode_create to be consistent with the other functions. Also document
where we need locking fixes and what the locks are for.
|
|
into origin/modesetting-101
Conflicts:
shared-core/i915_init.c - reconcile with airlied's new code
|
|
remove i915_driver_load fb related stuff. Add a small helper for setting up
outputs.
|
|
We need to keep a list of user created fbs to nuke on master exit.
We also need to use the bo properly.
|
|
|
|
- allow drm_buffer_object_create to be called w/o dev_mapping
- fixup i915 init code to allocate memory, fb and set modes right
- pass fb to drm_initial_config for setup
- change some debug output to make it easier to spot
- fixup lvds code to use DDC probing correctly
|
|
So far I can load fbcon, once I use my miniglx to add a framebuffer.
fbcon doesn't show anything on screen but baby steps and all that.
|
|
into origin/modesetting-101
Conflicts:
linux-core/drm_crtc.c - trivial merge
linux-core/drm_crtc.h - trivial merge
linux-core/intel_display.c - crtc_config -> mode_config
shared-core/i915_dma.c - accommodate new init code in i915_init.c
|
|
- move EDID structures to drm_edid.h
- add EDID info structure to drm_output
- add a few routines to intel_display for getting current mode info
- add some prototypes to intel_drv.h and drm_crtc.h
|
|
This still isn't perfect but it fixes a few oopses and cleans up
some of the tabs and bugs in the original fb limit code
|
|
X.org calls this crtc_config but this is a bad name and will confuse ppl later
(and me now :-)
|
