Add CodeQL Workflow for Code Security Analysis
This pull request introduces a CodeQL workflow to enhance the security analysis of our repository. CodeQL is a powerful static analysis tool that helps identify and mitigate security vulnerabilities in our codebase. By integrating this workflow into our GitHub Actions, we can proactively identify and address potential issues before they become security threats.
We added a new CodeQL workflow file (.github/workflows/codeql.yml) that
- Runs on every pull request (functionality to run on every push to main branches is included as a comment for convenience).
- Runs daily.
- Excludes queries with a high false positive rate or low-severity findings.
- Does not display results for git submodules, focusing only on our own codebase.
Testing:
To validate the functionality of this workflow, we have run several test scans on the codebase and reviewed the results. The workflow successfully compiles the project, identifies issues, and provides actionable insights while reducing noise by excluding certain queries and third-party code.
Deployment:
Once this pull request is merged, the CodeQL workflow will be active and automatically run on every push and pull request to the main branch. To view the results of these code scans, please follow these steps:
1. Under the repository name, click on the Security tab.
2. In the left sidebar, click Code scanning alerts.
Additional Information:
- You can further customize the workflow to adapt to your specific needs by modifying the workflow file.
- For more information on CodeQL and how to interpret its results, refer to the GitHub documentation and the CodeQL documentation (https://codeql.github.com/ and https://codeql.github.com/docs/).
Signed-off-by: Brian <bayuan@purdue.edu>
This replaces the previous scheme where scancodes were equal to keycodes
(an implausible and potentially misleading situation) with a set of
scancodes invented purely for the null platform.
This is partly based on the implementation of libdecor support in
PR #1693 by @ christianrauch.
Where available, the libdecor library is loaded at init and becomes the
preferred method for window decorations. On compositors that support
XDG decorations, libdecor in turn uses those. If not, libdecor has
a plug-in archtecture and may load additional libraries to either use
compositor-specific decorations or draw its own.
If necessary, support for libdecor can be disabled with the
GLFW_WAYLAND_LIBDECOR init hint. This is mostly in case some part of
the dynamic loading or duplication of header material added here turns
out to cause problems with future versions of libdecor-0.so.0.
Fixes#1639Closes#1693
Related to #1725
This commit simplifies the detection of which element of a fallback
decorated window the pointer has entered. Instead of looping through
the list of windows, the user pointer of fallback decoration surfaces is
set to the GLFW window object.
This replaces (one case of) manual management of weak links between
windows and monitors, both objects with complex life times, with
wl_object pointers used as opaque key values.
This is in preparation for adding support for libdecor, which creates
its own proxies on our display. It will likely also be helpful to some
people using native access on Wayland.
This is partly based on the implementation of libdecor support in
PR #1693 by @ christianrauch.
If a window was initially fullscreen then it would not get an XDG
decoration object. If the window was later switched to windowed mode it
would then get fallback decorations instead of XDG ones.
Fixes the following CI warning:
"Node.js 12 actions are deprecated. Please update the following
actions to use Node.js 16: actions/checkout@v2..."
Closes#2255
Because EGL ties client API support to configs, attempts to create
a context with an unavailable client API will fail with the unhelpful
"failed to find suitable config" error description.
This attempts to detect cases where there are usable configs for the
other client API and emit a hopefully more helpful error.
Related to #2173
We only care about displayable pixel formats (as defined in
WGL_ARB_pixel_format) for window context creation.
This changes pixel format enumeration to ignore non-displayable formats,
which are specified to be listed after displayable ones, by always using
the return value of DescribePixelFormat as the pixel format count.
On systems lacking the EGL_EXT_present_opaque extension, some
compositors treat any buffer with an alpha channel as per-pixel
transparent.
This commit ignores any EGLConfig with an alpha channel if the extension
is missing and the window is created with GLFW_TRANSPARENT_FRAMEBUFFER
set to false.
This is technically not a breaking change since GLFW_ALPHA_BITS is not
a hard constraint, but it is still going to inconvenience anyone using
the framebuffer alpa channel to store other kinds of data.
Related to #1895
This adds window hints for the initial position, in screen coordinates,
of a window. The special value GLFW_ANY_POSITION means the window
manager will be allowed to position the window.
It is not possible to set window positions on Wayland and GLFW will
always behave as if these hints are set to GLFW_ANY_POSITION.
Fixes#1603Fixes#1747
