linux-kernel - linux-next: manual merge of the drm tree with the jc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190624134147.4950d388@canb.auug.org.au>
Date:   Mon, 24 Jun 2019 13:41:47 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Dave Airlie <airlied@...ux.ie>,
        DRI <dri-devel@...ts.freedesktop.org>,
        Jonathan Corbet <corbet@....net>
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Maxime Ripard <maxime.ripard@...tlin.com>
Subject: linux-next: manual merge of the drm tree with the jc_docs tree

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  Documentation/fb/modedb.rst

between commit:

  ab42b818954c ("docs: fb: convert docs to ReST and rename to *.rst")

from the jc_docs tree and commit:

  1bf4e09227c3 ("drm/modes: Allow to specify rotation and reflection on the commandline")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/fb/modedb.rst
index 3c2397293977,1dd5a52f9390..000000000000
--- a/Documentation/fb/modedb.rst
+++ b/Documentation/fb/modedb.rst
@@@ -45,18 -45,29 +45,32 @@@ signals (e.g. HDMI and DVI-I). For othe
  is specified the output is disabled.
  
  You can additionally specify which output the options matches to.
 -To force the VGA output to be enabled and drive a specific mode say:
 +To force the VGA output to be enabled and drive a specific mode say::
 +
      video=VGA-1:1280x1024@...e
  
 -Specifying the option multiple times for different ports is possible, e.g.:
 +Specifying the option multiple times for different ports is possible, e.g.::
 +
      video=LVDS-1:d video=HDMI-1:D
  
+ Options can also be passed after the mode, using commas as separator.
+ 
+        Sample usage: 720x480,rotate=180 - 720x480 mode, rotated by 180 degrees
+ 
+ Valid options are:
+ 
+   - margin_top, margin_bottom, margin_left, margin_right (integer):
+     Number of pixels in the margins, typically to deal with overscan on TVs
+   - reflect_x (boolean): Perform an axial symmetry on the X axis
+   - reflect_y (boolean): Perform an axial symmetry on the Y axis
+   - rotate (integer): Rotate the initial framebuffer by x
+     degrees. Valid values are 0, 90, 180 and 270.
+ 
+ 
 -***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo *****
 +-----------------------------------------------------------------------------
  
  What is the VESA(TM) Coordinated Video Timings (CVT)?
 +=====================================================
  
  From the VESA(TM) Website:
  

Content of type "application/pgp-signature" skipped