Use subclassing from the drivers to allocate the objects. This saves
two objects being allocated for each crtc/output and generally makes
exit paths cleaner.
This splits a lot of the core modesetting code out into a file of
helper functions, that are only called from themselves and/or the driver.
The driver gets called into more often or can call these functions from itself
if it is a helper using driver.
I've broken framebuffer resize doing this but I didn't like the API for that
in any case.
drm_crtc->fb may point to NULL, f.e X server will allocate a new fb
and assign it to the CRTC at startup, when X server exits, it will destroy
the allocated fb, making drm_crtc->fb points to NULL.
Put off registering new outputs with sysfs until they're properly configured,
or we may get duplicates if the type hasn't been set yet (as is the case with
SDVO initialization). This also means moving de-registration into the cleanup
function instead of output destroy, since the latter occurs during the normal
course of setup when an output isn't found (and therefore not registered with
sysfs yet.
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.
so really want to get a list of modes per output not the global hammer list.
also we remove the mode ids and let the user pass back the full mode description
need to fix up add/remove mode for user modes now
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.
Since the drm_mode_card_res structure contains user pointers, we have to use
put_user and copy_to_user to write stuff out. The DRM ioctl wrapper will only
take care of copying the base drm_mode_card_res struct, not the included
arrays.
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.
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.
Conflicts:
linux-core/drm_crtc.c
linux-core/drm_fb.c
Lots of changes to merge with alanh's latest stuff:
o fix use of fb->pitch now that it has the right value
o add new helper for finding the CRTC given an FB
o fix new fb_probe/fb_remove functions to take a CRTC
o fixup callers of new FB routines
o port drm_fb changes to intel_fb
o check for errors after creating fb buffer object
o go back to using cfb_imageblit since the accel stubs aren't ready
places).
Add new FB hooks to the drm driver structure and make i915 use them for an
Intel specific FB driver. This will allow acceleration and better handling
of the command stream.
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.
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
- 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
Dave Airlie
Jesse Barnes
Hong Liu
Jakob Bornecrantz
Dave Airlie
Jesse Barnes
Alan Hourihane
Alan Hourihane
Jesse Barnes
Jakob Bornecrantz
Alan Hourihane
Jesse Barnes
Jesse Barnes
root
Dave Airlie
Jakob Bornecrantz
David Airlie