#
282199 |
|
28-Apr-2015 |
dumbbell |
drm: Update the device-independent code to match Linux 3.8.13
This update brings few features: o Support for the setmaster/dropmaster ioctls. For instance, they are used to run multiple X servers simultaneously. o Support for minor devices. The only user-visible change is a new entry in /dev/dri but it is useless at the moment. This is a first step to support render nodes [1].
The main benefit is to greatly reduce the diff with Linux (at the expense of an unreadable commit diff). Hopefully, next upgrades will be easier.
No updates were made to the drivers, beside adapting them to API changes.
[1] https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Render_nodes
r280814 is merged at the same time to avoid a short window where RANDR might be broken:
drm: Import Linux commit 9bc3cd5673d84d29272fa7181a4dfca83cbb48c1
Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri May 31 12:17:08 2013 +0000
drm: Sort connector modes based on vrefresh
Keeping the modes sorted by vrefresh before the pixel clock makes the mode list somehow more pleasing to the eye.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
PR: 198936 (r280814) Tested by: Many people MFC of: r280183, r280187 (original commit by glebius), r280814 Relnotes: yes
|
#
280369 |
|
23-Mar-2015 |
kib |
MFC r277487: An update for the i915 GPU driver, which brings the code up to Linux commit 4d93914ae3db4a897ead4b.
MFC r277959 (by adrian): Fix backlight for ivybridge based laptops (and whatever else comes through this codepath.)
MFC r278146: Do not attach to the unsupported chipsets, unless magic tunable is frobbed.
MFC r278147, r278148: Fix sign for the error code returned from the driver-specific code.
MFC r278152: Do not access gmbus_ports array past its end.
MFC r278159 (by emaste): Remove duplicate intel_fbc_enabled prototype.
|
#
274865 |
|
22-Nov-2014 |
dumbbell |
drm: Take vt(4) default mode from loader tunables
By default, vt(4) gets the "preferred mode" from DRM, when using a DRM video driver as its backend. The preferred mode is usually the native screen resolution.
Now, if this mode isn't appropriate, a user can use loader tunables to select a mode. The tunables are read in the following order: 1. kern.vt.fb.modes.$connector_name 2. kern.vt.fb.default_mode
For example, to set a 1024x768 mode, no matter the connector: kern.vt.fb.default_mode="1024x768"
To set a 800x600 mode only on the laptop builtin screen: kern.vt.fb.modes.LVDS-1="800x600"
Beside r274031, this MFC includes:
r274049: drm: When reading connector mode tunables, list connectors
... and their associated tunables. This gives a way to know the list of available connectors, no matter the driver.
The problem is that xrandr(1) can list connectors but it uses a different naming.
r274050: vt(4): Document kern.vt.fb.default_mode and kern.vt.fb.modes.*
Those tunables are used to set a specific mode in vt(4) instead of using the default mode.
Differential Revision: https://reviews.freebsd.org/D1098 Reviewed by: ak@, emaste@, kwm@
r274051: vt(4): Improve the description of kern.vt.fb.modes.$connector
Differential Revision: https://reviews.freebsd.org/D1098 Submitted by: emaste@
r274053: vt(4): Start new sentences on their own lines
Submitted by: brueffer@
MFC of: r274031, r274049, r274050, r274051, r274053
|
#
272104 |
|
25-Sep-2014 |
ray |
MFC r268981 Remove #ifdef-s to reduce difference to upstream.
Pointed by: kib Approved by: re (glebius)
Sponsored by: The FreeBSD Foundation
|
#
271769 |
|
18-Sep-2014 |
dumbbell |
vt(4): Merge several bug fixes and improvements
SVN revisions in this MFC: 269779 270705 270706 271180 271250 271253 271682 271684
Detailed commit list:
r269779: fbd: Fix a bug where vt_fb_attach() success would be considered a failure
vt_fb_attach() currently always returns 0, but it could return a code defined in errno.h. However, it doesn't return a CN_* code. So checking its return value against CN_DEAD (which is 0) is incorrect, and in this case, a success becomes a failure.
The consequence was unimportant, because the caller (drm_fb_helper.c) would only log an error message in this case. The console would still work.
Approved by: nwhitehorn
r270705: vt(4): Add cngrab() and cnungrab() callbacks
They are used when a panic occurs or when entering a DDB session for instance.
cngrab() forces a vt-switch to the console window, no matter if the original window is another terminal or an X session. However, cnungrab() doesn't vt-switch back to the original window currently.
r270706: drm: Don't "taskqueue" vt-switch if under DDB/panic situation
If DDB is active, we can't use a taskqueue thread to switch away from the X window, because this thread can't run.
Reviewed by: ray@ Approved by: ray@
r271180: vt_vga: vd_setpixel_t and vd_drawrect_t are noop in text mode
r271250: vt(4): Change the terminal and buffer sizes, even without a font
This fixes a bug where scroll lock would not work for tty #0 when using vt_vga's textmode. The reason was that this window is created with a static 256x100 buffer, larger than the real size of 80x25.
Now, in vt_change_font() and vt_compute_drawable_area(), we still perform operations even of the window has no font loaded (this is the case in textmode here vw->vw_font == NULL). One of these operation resizes the buffer accordingly.
In vt_compute_drawable_area(), we take the terminal size as is (ie. 80x25) for the drawable area.
The font argument to vt_set_border() is removed (it was never used) and the code now uses the computed drawable area instead of re-doing its own calculation.
Reported by: Harald Schmalzbauer <h.schmalzbauer_omnilan.de> Tested by: Harald Schmalzbauer <h.schmalzbauer_omnilan.de>
r271253: pause_sbt(): Take the cold path (ie. use DELAY()) if KDB is active
This fixes a panic in the i915 driver when one uses debug.kdb.enter=1 under vt(4).
PR: 193269 Reported by: emaste@ Submitted by: avg@
r271682: vt(4): Fix a LOR which occurs during a call to vt_upgrade()
Reported by: kib@ Review: https://reviews.freebsd.org/D785 Reviewed by: ray@ Approved by: ray@
r271684: vt(4): Use vt_fb_drawrect() and vt_fb_setpixel() in all vt_fb-derivative
Review: https://reviews.freebsd.org/D789 Reviewed by: nwhitehorn Approved by: nwhitehorn
Approved by: re (gjb)
|
#
262861 |
|
06-Mar-2014 |
jhb |
MFC 259016,259019,259049,259071,259102,259110,259129,259130,259178,259179, 259203,259221,259261,259532,259615,259650,259651,259667,259680,259727, 259761,259772,259776,259777,259830,259882,259915,260160,260449,260450, 260688,260888,260953,261269,261547,261551,261552,261553,261585: Merge the vt(4) driver (newcons) to stable/10.
Approved by: ray
|
#
282199 |
|
28-Apr-2015 |
dumbbell |
drm: Update the device-independent code to match Linux 3.8.13
This update brings few features: o Support for the setmaster/dropmaster ioctls. For instance, they are used to run multiple X servers simultaneously. o Support for minor devices. The only user-visible change is a new entry in /dev/dri but it is useless at the moment. This is a first step to support render nodes [1].
The main benefit is to greatly reduce the diff with Linux (at the expense of an unreadable commit diff). Hopefully, next upgrades will be easier.
No updates were made to the drivers, beside adapting them to API changes.
[1] https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Render_nodes
r280814 is merged at the same time to avoid a short window where RANDR might be broken:
drm: Import Linux commit 9bc3cd5673d84d29272fa7181a4dfca83cbb48c1
Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri May 31 12:17:08 2013 +0000
drm: Sort connector modes based on vrefresh
Keeping the modes sorted by vrefresh before the pixel clock makes the mode list somehow more pleasing to the eye.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
PR: 198936 (r280814) Tested by: Many people MFC of: r280183, r280187 (original commit by glebius), r280814 Relnotes: yes
|
#
280369 |
|
23-Mar-2015 |
kib |
MFC r277487: An update for the i915 GPU driver, which brings the code up to Linux commit 4d93914ae3db4a897ead4b.
MFC r277959 (by adrian): Fix backlight for ivybridge based laptops (and whatever else comes through this codepath.)
MFC r278146: Do not attach to the unsupported chipsets, unless magic tunable is frobbed.
MFC r278147, r278148: Fix sign for the error code returned from the driver-specific code.
MFC r278152: Do not access gmbus_ports array past its end.
MFC r278159 (by emaste): Remove duplicate intel_fbc_enabled prototype.
|
#
274865 |
|
22-Nov-2014 |
dumbbell |
drm: Take vt(4) default mode from loader tunables
By default, vt(4) gets the "preferred mode" from DRM, when using a DRM video driver as its backend. The preferred mode is usually the native screen resolution.
Now, if this mode isn't appropriate, a user can use loader tunables to select a mode. The tunables are read in the following order: 1. kern.vt.fb.modes.$connector_name 2. kern.vt.fb.default_mode
For example, to set a 1024x768 mode, no matter the connector: kern.vt.fb.default_mode="1024x768"
To set a 800x600 mode only on the laptop builtin screen: kern.vt.fb.modes.LVDS-1="800x600"
Beside r274031, this MFC includes:
r274049: drm: When reading connector mode tunables, list connectors
... and their associated tunables. This gives a way to know the list of available connectors, no matter the driver.
The problem is that xrandr(1) can list connectors but it uses a different naming.
r274050: vt(4): Document kern.vt.fb.default_mode and kern.vt.fb.modes.*
Those tunables are used to set a specific mode in vt(4) instead of using the default mode.
Differential Revision: https://reviews.freebsd.org/D1098 Reviewed by: ak@, emaste@, kwm@
r274051: vt(4): Improve the description of kern.vt.fb.modes.$connector
Differential Revision: https://reviews.freebsd.org/D1098 Submitted by: emaste@
r274053: vt(4): Start new sentences on their own lines
Submitted by: brueffer@
MFC of: r274031, r274049, r274050, r274051, r274053
|
#
272104 |
|
25-Sep-2014 |
ray |
MFC r268981 Remove #ifdef-s to reduce difference to upstream.
Pointed by: kib Approved by: re (glebius)
Sponsored by: The FreeBSD Foundation
|
#
271769 |
|
18-Sep-2014 |
dumbbell |
vt(4): Merge several bug fixes and improvements
SVN revisions in this MFC: 269779 270705 270706 271180 271250 271253 271682 271684
Detailed commit list:
r269779: fbd: Fix a bug where vt_fb_attach() success would be considered a failure
vt_fb_attach() currently always returns 0, but it could return a code defined in errno.h. However, it doesn't return a CN_* code. So checking its return value against CN_DEAD (which is 0) is incorrect, and in this case, a success becomes a failure.
The consequence was unimportant, because the caller (drm_fb_helper.c) would only log an error message in this case. The console would still work.
Approved by: nwhitehorn
r270705: vt(4): Add cngrab() and cnungrab() callbacks
They are used when a panic occurs or when entering a DDB session for instance.
cngrab() forces a vt-switch to the console window, no matter if the original window is another terminal or an X session. However, cnungrab() doesn't vt-switch back to the original window currently.
r270706: drm: Don't "taskqueue" vt-switch if under DDB/panic situation
If DDB is active, we can't use a taskqueue thread to switch away from the X window, because this thread can't run.
Reviewed by: ray@ Approved by: ray@
r271180: vt_vga: vd_setpixel_t and vd_drawrect_t are noop in text mode
r271250: vt(4): Change the terminal and buffer sizes, even without a font
This fixes a bug where scroll lock would not work for tty #0 when using vt_vga's textmode. The reason was that this window is created with a static 256x100 buffer, larger than the real size of 80x25.
Now, in vt_change_font() and vt_compute_drawable_area(), we still perform operations even of the window has no font loaded (this is the case in textmode here vw->vw_font == NULL). One of these operation resizes the buffer accordingly.
In vt_compute_drawable_area(), we take the terminal size as is (ie. 80x25) for the drawable area.
The font argument to vt_set_border() is removed (it was never used) and the code now uses the computed drawable area instead of re-doing its own calculation.
Reported by: Harald Schmalzbauer <h.schmalzbauer_omnilan.de> Tested by: Harald Schmalzbauer <h.schmalzbauer_omnilan.de>
r271253: pause_sbt(): Take the cold path (ie. use DELAY()) if KDB is active
This fixes a panic in the i915 driver when one uses debug.kdb.enter=1 under vt(4).
PR: 193269 Reported by: emaste@ Submitted by: avg@
r271682: vt(4): Fix a LOR which occurs during a call to vt_upgrade()
Reported by: kib@ Review: https://reviews.freebsd.org/D785 Reviewed by: ray@ Approved by: ray@
r271684: vt(4): Use vt_fb_drawrect() and vt_fb_setpixel() in all vt_fb-derivative
Review: https://reviews.freebsd.org/D789 Reviewed by: nwhitehorn Approved by: nwhitehorn
Approved by: re (gjb)
|
#
262861 |
|
06-Mar-2014 |
jhb |
MFC 259016,259019,259049,259071,259102,259110,259129,259130,259178,259179, 259203,259221,259261,259532,259615,259650,259651,259667,259680,259727, 259761,259772,259776,259777,259830,259882,259915,260160,260449,260450, 260688,260888,260953,261269,261547,261551,261552,261553,261585: Merge the vt(4) driver (newcons) to stable/10.
Approved by: ray
|