include: nuttx: video: nxstyle fixes

Nxstyle fixes to pass CI

Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
This commit is contained in:
Alin Jerpelea 2021-01-26 09:54:30 +01:00 committed by Xiang Xiao
parent f29beab982
commit 9491f4a9f1
7 changed files with 78 additions and 66 deletions

View file

@ -1,4 +1,4 @@
/********************************************************************************************
/****************************************************************************
* include/nuttx/video/edid.h
* EDID (Extended Display Identification Data) Format
*
@ -7,8 +7,8 @@
*
* Reference: Wikipedia (initial version)
*
* Updated and extended with definitions from FreeBSD which has a compatible 2-clause BSD
* license:
* Updated and extended with definitions from FreeBSD which has a compatible
* 2-clause BSD license:
*
* Copyright (c) 2006 Itronix Inc. All rights reserved.
* Written by Garrett D'Amore for Itronix Inc.
@ -40,25 +40,26 @@
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*
********************************************************************************************/
****************************************************************************/
#ifndef __INCLUDE_NUTTX_VIDEO_EDID_H
#define __INCLUDE_NUTTX_VIDEO_EDID_H
/********************************************************************************************
/****************************************************************************
* Included Files
********************************************************************************************/
****************************************************************************/
#include <stdint.h>
#include <nuttx/video/videomode.h>
/********************************************************************************************
/****************************************************************************
* Pre-processor Definitions
********************************************************************************************/
****************************************************************************/
#define EDID_LENGTH 128
/* EDID data offsets ************************************************************************/
/* EDID data offsets ********************************************************/
/* Bytes 0-7: Header Information */
#define EDID_HEADER_MAGIC_OFFSET 0 /* Fixed header pattern: 00 FF FF FF FF FF FF 00 */
@ -141,7 +142,7 @@
#define EDID_TRAILER_NEXTENSIONS_OFFSET 126 /* Number of extensions to follow */
#define EDID_TRAILER_CHECKSUM_OFFSET 127 /* Checksum. Sum of all 128 bytes should equal 0 */
/* EDID Bitfield Definitions ****************************************************************/
/* EDID Bitfield Definitions ************************************************/
#define EDID_MAGIC {0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0}
@ -425,7 +426,8 @@
#define EDID_DESC_ZERO_3 4 /* Byte 4: Zero */
#define EDID_DESC_INFO 5 /* Bytes 5-17: Determined by descriptor type */
/* 0x00-0x0f: Manufacturer reserved descriptors */
/* 0x00-0x0f: Manufacturer reserved descriptors */
#define EDID_DESCTYPE_DUMMY 0x10 /* Dummy identifier */
#define EDID_DESCTYPE_STDTIMING 0xf7 /* Additional standard timing 3 */
#define EDID_DESCTYPE_CVT 0xf8 /* CVT 3-Byte Timing Codes */
@ -467,7 +469,8 @@
#define EDID_DESC_STD_TIMING_START_OFFSET 5
#define EDID_DESC_STD_TIMING_COUNT_OFFSET 6
/* Extended EDID data offsets ****************************************************************/
/* Extended EDID data offsets ***********************************************/
/* To be provided */
/* EDID Extensions assigned by VESA (First byte of the Extended EDID block) */
@ -490,9 +493,9 @@
* from manufacturer. However, the value is
* later used by DDDB. */
/********************************************************************************************
/****************************************************************************
* Pre-processor Definitions
********************************************************************************************/
****************************************************************************/
/* These structures is a user-friendly digest of the EDID data. */
@ -551,30 +554,30 @@ struct edid_info_s
struct videomode_s edid_modes[64];
};
/********************************************************************************************
/****************************************************************************
* Public Function Prototypes
********************************************************************************************/
****************************************************************************/
/********************************************************************************************
/****************************************************************************
* Name: edid_parse
*
* Description:
* Given a block of raw EDID data, parse the data and convert it to the 'digested' form
* of struct edid_info_s.
* Given a block of raw EDID data, parse the data and convert it to the
* 'digested' form of struct edid_info_s.
*
* Input Parameters:
* data - A reference to the raw EDID data
* edid - The location to return the digested EDID data.
*
* Returned Value:
* Zero (OK) is returned on success; otherwise a negated errno value is returned to
* indicate the nature of the failure.
* Zero (OK) is returned on success; otherwise a negated errno value is
* returned to indicate the nature of the failure.
*
********************************************************************************************/
****************************************************************************/
int edid_parse(FAR const uint8_t *data, FAR struct edid_info_s *edid);
/********************************************************************************************
/****************************************************************************
* Name: edid_dump
*
* Description:
@ -586,7 +589,7 @@ int edid_parse(FAR const uint8_t *data, FAR struct edid_info_s *edid);
* Returned Value:
* None
*
********************************************************************************************/
****************************************************************************/
void edid_dump(FAR const struct edid_info_s *edid);

View file

@ -48,6 +48,7 @@ extern "C"
/****************************************************************************
* Public Function Prototypes
****************************************************************************/
FAR struct video_devops_s *isx012_initialize(void);
int isx012_uninitialize(void);

View file

@ -34,7 +34,7 @@
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*
*****************************************************************************/
****************************************************************************/
#ifndef __INCLUDE_NUTTX_VIDEO_MAX7456_H
#define __INCLUDE_NUTTX_VIDEO_MAX7456_H
@ -78,4 +78,4 @@ struct mx7_config_s
int max7456_register(FAR const char *path, FAR struct mx7_config_s *config);
#endif /*__INCLUDE_NUTTX_VIDEO_MAX7456_H */
#endif /* __INCLUDE_NUTTX_VIDEO_MAX7456_H */

View file

@ -129,9 +129,9 @@ struct rfb_selected_sectype_s
};
/* "If number-of-security-types is zero, then for some reason the connection
* failed (e.g. the server cannot support the desired protocol version). This
* is followed by a string describing the reason (where a string is specified
* as a length followed by that many ASCII characters):
* failed (e.g. the server cannot support the desired protocol version).
* This is followed by a string describing the reason (where a string is
* specified as a length followed by that many ASCII characters):
*/
struct rfb_sectype_connfail_s
@ -154,10 +154,10 @@ struct rfb_sectype_s
/* "Once the security-type has been decided, data specific to that security-
* type follows (see section 6.2 for details). At the end of the security
* handshaking phase, the protocol normally continues with the SecurityResult
* message. Note that after the security handshaking phase, it is possible
* that further protocol data is over an encrypted or otherwise altered
* channel."
* handshaking phase, the protocol normally continues with the
* SecurityResult message. Note that after the security handshaking phase,
* it is possible that further protocol data is over an encrypted or
* otherwise altered channel."
*/
/* 6.1.3 SecurityResult
@ -289,18 +289,18 @@ struct rfb_serverinit_s
* "Bits-per-pixel is the number of bits used for each pixel value on the
* wire. This must be greater than or equal to the depth which is the number
* of useful bits in the pixel value. Currently bits-per-pixel must be 8,
* 16 or 32less than 8-bit pixels are not yet supported. Big-endian-flag is
* non-zero (true) if multi-byte pixels are interpreted as big endian. Of
* course this is meaningless for 8 bits-per-pixel.
* 16 or 32less than 8-bit pixels are not yet supported. Big-endian-flag
* is non-zero (true) if multi-byte pixels are interpreted as big endian.
* Of course this is meaningless for 8 bits-per-pixel.
*
* "If true-colour-flag is non-zero (true) then the last six items specify
* how to extract the red, green and blue intensities from the pixel value.
* Red-max is the maximum red value (= 2n 1 where n is the number of bits
* used for red). Note this value is always in big endian order. Red-shift
* is the number of shifts needed to get the red value in a pixel to the
* least significant bit. Green-max, green-shift and blue-max, blue-shift
* are similar for green and blue. For example, to find the red value
* (between 0 and red-max) from a given pixel, do the following:
* Red-max is the maximum red value (= 2n 1 where n is the number of
* bits used for red). Note this value is always in big endian order.
* Red-shift is the number of shifts needed to get the red value in a pixel
* to the least significant bit. Green-max, green-shift and blue-max,
* blue-shift are similar for green and blue. For example, to find the red
* value (between 0 and red-max) from a given pixel, do the following:
*
* - "Swap the pixel value according to big-endian-flag (e.g. if
* big-endian-flag is zero (false) and host byte order is big endian,
@ -440,18 +440,19 @@ struct rfb_keyevent_s
*
* - "The 'shift state' (i.e. whether either of the Shift keysyms are down)
* should only be used as a hint when interpreting a keysym. For
* example, on a US keyboard the # character is shifted, but on a UK
* keyboard it is not. A server with a US keyboard receiving a #
* character from a client with a UK keyboard will not have been sent
* any shift presses. In this case, it is likely that the server will
* internally need to 'fake' a shift press on its local system, in order
* to get a # character and not, for example, a 3.
* example, on a US keyboard the # character is shifted, but on a
* UK keyboard it is not. A server with a US keyboard receiving a
* # character from a client with a UK keyboard will not have been
* sentany shift presses.
* In this case, it is likely that the server will internally need to
* 'fake' a shift press on its local system, in order to get a #
* character and not, for example, a 3.
* - "The difference between upper and lower case keysyms is significant.
* This is unlike some of the keyboard processing in the X Window System
* which treats them as the same. For example, a server receiving an
* uppercase A keysym without any shift presses should interpret it
* as an uppercase A. Again this may involve an internal 'fake' shift
* press.
* This is unlike some of the keyboard processing in the X Window
* System which treats them as the same. For example, a server receiving
* an uppercase A keysym without any shift presses should
* interpret it as an uppercase A.
* Again this may involve an internal fake shift press.
* - "Servers should ignore 'lock' keysyms such as CapsLock and NumLock
* where possible. Instead they should interpret each character-based
* keysym according to its case.
@ -463,7 +464,7 @@ struct rfb_keyevent_s
* - "On a viewer where modifiers like Control and Alt can also be used to
* generate character-based keysyms, the viewer may need to send extra
* 'release' events in order that the keysym is interpreted correctly.
* For example, on a German PC keyboard, ctrl-alt-q generates the @
* For example, on a German PC keyboard, ctrl-alt-q generates the "@"
* character. In this case, the viewer needs to send 'fake' release
* events for Control and Alt in order that the @ character is
* interpreted correctly (ctrl-alt-@is likely to mean something
@ -783,8 +784,8 @@ struct rfb_rrerect32_s
* the tile). Otherwise the other bits in the mask are as follows:
*
* "BackgroundSpecified - if set, a pixel value follows which specifies the
* background colour for this tile:"
*/
* background colour for this tile:"
*/
struct rfb_backpixel8_s
{
@ -943,7 +944,6 @@ struct rfb_srle_s
#define RFB_SUBENCODING_RLE 128 /* Plain RLE */
#define RFB_SUBENCODING_PALRLE 129 /* Palette RLE */
/* "Raw pixel data. width x height pixel values follow (where width and
* height are the width and height of the tile):"
*/
@ -1038,7 +1038,8 @@ struct rfb_palette32_s
};
/* Then as with plain RLE, consists of a number of runs, repeated until the
* tile is done. A run of length one is represented simply by a palette index:
* tile is done. A run of length one is represented simply by a palette
* index:
*/
struct rfb_palettendx_s
@ -1079,9 +1080,9 @@ struct rfb_palettendx_s
* that it is capable of coping with a change in the framebuffer width
* and/or height. The server changes the desktop size by sending a
* pseudo-rectangle with the DesktopSize pseudo-encoding as the last
* rectangle in an update. The pseudo-rectangles x-position and y-position
* are ignored, and width and height indicate the new width and height of
* the framebuffer. There is no further data associated with the
* rectangle in an update. The pseudo-rectangles x-position and
* y-position are ignored, and width and height indicate the new width and
* height of the framebuffer. There is no further data associated with the
* pseudo-rectangle.
*/

View file

@ -44,7 +44,9 @@
/****************************************************************************
* Pre-processor Definitions
****************************************************************************/
/* Color Creation and Conversion Macros *************************************/
/* This macro creates RGB24 from 8:8:8 RGB */
#define RGBTO24(r,g,b) \
@ -100,6 +102,7 @@
(((rgb16 & 0xf800) << 8) | ((rgb16 & 0x07e0) << 5) | ((rgb16 & 0x001f) << 3))
/* Standard Color Definitions ***********************************************/
/* RGB24-888: 00000000 RRRRRRRR GGGGGGGG BBBBBBBB */
#define RGB24_BLACK 0x00000000
@ -226,7 +229,9 @@
#define RGB12_SNOW 0x0fff
#define RGB12_YELLOW 0x0ff0
/* RGB8-332: RRRGGGBB (really not enough color resolution for the following) */
/* RGB8-332: RRRGGGBB
* (really not enough color resolution for the following)
*/
#define RGB8_BLACK 0x00
#define RGB8_WHITE 0xff

View file

@ -1,4 +1,4 @@
/**************************************************************************7
/****************************************************************************
* include/nuttx/video/vesagtf.h
* EDID (Extended Display Identification Data) Format
*
@ -38,7 +38,7 @@
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*
********************************************************************************************/
****************************************************************************/
#ifndef __INCLUDE_NUTTX_VIDEO_VESAGTF
#define __INCLUDE_NUTTX_VIDEO_VESAGTF
@ -113,7 +113,9 @@ void vesagtf_mode(unsigned int x, unsigned int y, unsigned int refresh,
*
****************************************************************************/
void vesagtf_mode_params(unsigned int x, unsigned int y, unsigned int refresh,
void vesagtf_mode_params(unsigned int x,
unsigned int y,
unsigned int refresh,
FAR struct vesagtf_params *params,
unsigned int flags,
FAR struct videomode_s *videomode);

View file

@ -68,7 +68,7 @@ extern "C"
#endif
/****************************************************************************
* Public Functions
* Public Functions Definitions
****************************************************************************/
int video_common_notify_dma_done(uint8_t err_code,