Giter VIP home page Giter VIP logo

wlroots's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wlroots's Issues

Type refactoring

  • Move headers around
  • Move support code around
  • Figure out a consistent naming scheme for event types

initializer element is not a constant expression

make
Scanning dependencies of target man
[  0%] Built target man
Scanning dependencies of target wlr-util
[  1%] Building C object util/CMakeFiles/wlr-util.dir/list.c.o
[  3%] Building C object util/CMakeFiles/wlr-util.dir/log.c.o
/home/shana/builds/wlroots/util/log.c: In function ‘_strip_path’:
/home/shana/builds/wlroots/util/log.c:68:22: error: initializer element is not a constant expression [-Werror]
  static int srclen = strlen(WLR_SRC_DIR) + 1;
                      ^
/home/shana/builds/wlroots/util/log.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-lto-type-mismatch’ [-Werror]
cc1: all warnings being treated as errors
make[2]: *** [util/CMakeFiles/wlr-util.dir/build.make:87: util/CMakeFiles/wlr-util.dir/log.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:346: util/CMakeFiles/wlr-util.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

Snippet of the code:

// strips the path prefix from filepath
// will try to strip WLR_SRC_DIR as well as a relative src dir
// e.g. '/src/build/wlroots/backend/wayland/backend.c' and
// '../backend/wayland/backend.c' will both be stripped to
// 'backend/wayland/backend.c'
const char *_strip_path(const char *filepath) {
        static int srclen = strlen(WLR_SRC_DIR) + 1;
        if (strstr(filepath, WLR_SRC_DIR) == filepath) {
                filepath += srclen;
        } else if (*filepath == '.') {
                while (*filepath == '.' || *filepath == '/') {
                        ++filepath;
                }
        }
        return filepath;
}

I changed srclen to non-static and it compiled properly.
Alternatively, separating them to 2 lines also works:

        static int srclen;
        srclen = strlen(WLR_SRC_DIR) + 1;

Use GL_KHR_debug

Currently we use a macro (GL_CALL) to wrap around each of the OpenGL functions to check glError and log if anything went wrong. It works, but it's used inconsistently (e.g. outside of wlr-render) and is ugly, in my opinion.

With this OpenGL extension, we can set log handlers that the OpenGL implementation will call when something goes wrong and actually get better quality debug messages than what we have currently.

A disadvantage of this is that we will lose the ability to print line numbers of where the error specifically happens. The extension does have some ways to get some arbitrary data into the messages, so we could probably do as good as file + function.

Implement screenshot protocol

So the original idea for the screenshooter is to implement weston's protocol: https://github.com/wayland-project/weston/blob/master/protocol/weston-screenshooter.xml

Though, this protocol has some issues, discussed here: https://lists.freedesktop.org/archives/wayland-devel/2013-December/thread.html#12571. Also, this protocol is just a demo, not a standard.

Orbital has fixed one of them, by adding a screenshot interface: https://github.com/giucam/orbital/blob/gamma/protocol/screenshooter.xml

So we have 3 solutions:

  1. Implement weston's protocol
  2. Implement orbital's protocol
  3. Design another protocol, and propose it as a standard

Output layout autoconfiguration

An auto configured output is positioned in a sensible place on the screen. The user does not specify coordinates for an auto configured output, rather the coordinates are adjusted dynamically whenever the layout changes. An output that is not auto configured is called manually configured.

The use case is for compositors that don't want to require user configuration for outputs within the layout.

Auto configuration is presently implemented in examples/config.c:configure_layout() but should be moved into wlroots.

/**
* Add an auto configured output to the layout. This will place the output in a
* sensible location in the layout. The coordinates of the output in the layout
* may adjust dynamically when the layout changes. If the output is already in
* the layout, it will become auto configured. If the position of the output is
* set such as with `wlr_output_layout_move()`, the output will become manually
* configured.
*/
void wlr_output_layout_add_auto(struct wlr_output_layout *layout, struct wlr_output *output);

Add detection of no input devices

Currently with the libinput backend, if you cannot open /dev/input/event* for whatever reason (e.g. no permissions), the rest of the compositor will open up, leaving you stuck and unable to close it. It's pretty annoying, as you need to restart your computer using the power button when it happens.

Libinput doesn't report any errors about being unable to open files, so an explicit check needs to happen somewhere to make sure we actually have an input device, and close the compositor if we don't.

give compositor.c example reference implmentation status

The term "compositor" seems to be heavily overloaded and it's leading to some confusion with the term.

The compositor.c seems to becoming our reference implementation because all the new features are being integrated with it. So I suggest we give the project a real name and official reference implementation status that people can use like documentation.

My suggestion is to call it "rootston" but you might think that's dumb.

wlroots examples/rotation doesn't rotate properly

My setup:

  • Intel® HD Graphics 3000
  • LVDS-1: 1366x768
  • VGA-1: 1280x1024

How to trigger the bug:

./build/rotation -o VGA-1 -r 90

Expected:

Output on the VGA-1 monitor is rotated by 90 degrees.

What happens:

  • Output on Laptop screen (LVDS-1) looks fine.
  • The output on VGA-1 is not rotated, but it cuts off.
  • The right most tile doesn't "flow out" but suddenly disapears.
    video

Bisect:

With git bisect I found the following interesting commits:

Additional info:

rotation -o VGA-1 -r 180 doesn't rotate anything either, but doesn't cut off.

Expose internals to end users

wlr/backend/drm.h should expose APIs for doing things like getting the DRM fd, getting GBM BO references, events on page flip and so on. Similar tools should be available for all internals.

Xwayland zombies

Currently if Xwayland crashes or gets killed, we will start a new Xwayland and recover back to useable state but will never attempt to reap the process, leaving a zombie behind.

The shutdown code cannot do a waitpid() call, because for example on normal Xwayland shutdown it will tell us to destroy the wl client before the process ends, so we would just deadlock.

I can see two alternatives to reap this properly:

  • Either have an handler for SIGCHLD, this would not be xwayland specific but we could just reap stuff as they come and eventually have a list of actions for specific pid deaths (weston does that)
  • We could say we never will care about that process and double-fork to spawn Xwayland. It will then be taken by init and reaped whenever it dies - we will still get the notification from its wayland client being destroyed as we do now, so for all intent and purpose it will work for us.
    The only thing we lose is that we will no longer know what pid Xwayland is started as - but while we store that information we never use it so it isn't a big loss.

Thoughts?

DisplayPort MST

This is a tracking issue for DisplayPort MST (Multi-Stream Transport), which is the ability for multiple monitors to come off the same DisplayPort connector. It's also used in Dual-panel 4K monitors and many modern laptop docks.

Unfortunately, I don't have a lot of the hardware to implement this all properly or even be certain about the requirements for it. I DO own a monitor that is MST compatible, but the radeon drivers are messed up with my GPU, so I can't get it working.

Based on my understanding (I may be wrong), what we need to do is

  • Handle DRM connectors being able to appear at any point
  • Handle DRM connectors being able to disappear at any point
  • Naming the connectors properly (e.g. DP-1-1, DP-1-2)
  • Being able to handle the DRM tiling property (for dual-panel 4K screens), possibly exposing dual-panels as a single logical monitor?

alloc error handling

In some places wlroots check if an alloc function returns NULL, in others it does not (and will simply crash).
In most places when alloc returns NULL things are going to blow up anyways (or things are getting weird), i guess the best thing to do would output an error and exit.
We could remove a lot of repetitive checks and boilerplate and at the same time transform in other places a segmentation fault on alloc error into an error message and exit by introducing a macro/function that simply logs the allocation error and exits on failure and otherwise is guaranteed to return a valid pointer.
This is how weston does it, would something like this be acceptable in wlroots?

Compositor ideas

Starting a thread to dump ideas of things I want to be possible for wlroots-based compositors to implement. Here's a few of the ideas that have been bouncing around in my head:

  • Let compositor handle focus semantics by just letting them attach an arbitrary number of input devices to an arbitrary number of clients
  • Add or remove backends on the fly, including support for i.e. displaying an output on the wayland backend on an output running the DRM backend
  • Access to internal wlroots resources to implement pretty much any extensions you want
  • Implementing custom versions of any type, like virtual outputs or remote input devices or anything else (compositor might optionally have plugin support that could take advantage of this too)
  • Separate keyboard layouts for separate keyboards or even separate applications
  • Multiple cursors and/or
  • simulated multitouch with multiple mice
  • Rendering individual surfaces with arbitrary shaders or arbitrary transformations

Most of these shouldn't be explicitly supported features in wlroots, but rather should be possible as a consequence of its flexible design. Feel free to add more for discussion and we'll see if it makes sense for wlroots to accomodate these use-cases.

wlroots rotation exits after hot-unplugging

I tested hotplugging the VGA-1 output on my Intel HD 3000.

Plugging it in while ./build/examples/rotation is running is detected, and the display is used.

Unplugging it shuts down the application after a few seconds. Here is a log of plugging the display in and unplugging.
It does not make a difference, whether the display was plugged in when starting rotation, or got plugged in while rotation is running.

-Wlto-type-mismatch

Building wlroots with link time optimisation (-flto) causes this error to be raised by GCC.
It's being caused by the whole overloaded "wlr_backend_state" thing, where it had multiple, different definitions.

I feel we should change how all of that is handled, so we can safely build with LTO.

[proposal] Common user interface for mode switching

It would be convenient if wlroots-based compositors could share some tooling for things they would almost certainly implement themselves. Switching monitor modes and positions at runtime is a core feature that everybody uses on the linux desktop.

What's really nice about X is that we have a common way to do these things. No matter what DE I use, I can set up my monitor with tools like xrandr and arandr.

I propose that we set up a dbus interface with methods that can configure monitors. Then someone could write an equivalent arandr for wlroots compositors that could be shared between the projects.

wl_seat design

Wayland's design choices:

  • There are any number of seats allocated globally
  • Each seat has up to one keyboard, pointer, or touch device
  • Pointers...
    • Have events for entering and leaving surfaces and input events
    • Can have a custom cursor set by the client
  • Keyboards...
    • Offer an XKB keymap to the client
    • Have events for entering and leaving surfaces, input events, and key repeat info
  • Touch...
    • Has input events

We are not going to directly associate wlr_input_device with this. Instead, wlr_shell will expose functions for managing how it presents itself to the user (what capabilities it has) and the shell will transparently handle the rest involved in presenting these capabilities to the user. For example, the compositor can ask the shell to start supporting keyboard events, and it will emit a wl_seat_capabilities event and start offering clients a wl_keyboard. The seat will then offer utility functions for the compositor to post events with. IMO wl_{pointer,keyboard,touch} unnecessarily complicates things and we don't need wlr_shell to expose them to compositors.

struct wlr_seat {
	// ...
    struct {
		/** Raised when a client sets the cursor for its pointer */
		struct wl_signal cursor_set;
	} events;
};

struct wlr_seat *wlr_seat_create(struct wl_display *display, const char *name);

void wlr_seat_configure_capabilities(struct wlr_seat *seat,
		enum wl_seat_capabilities caps);

void wlr_seat_pointer_enter(struct wlr_seat *seat, struct wl_resource *surface,
		wl_fixed_t surface_x, wl_fixed_t surface_y);

// and so on

High level API design discussion

Opening this issue to start a discussion about some high level API designs I have in mind. Feel free to propose more high level APIs here as well.

wlr_output_layout

This should encapsulate some of the concepts required for a virtual desktop of multiple outputs.

struct wlr_output_layout_state;
struct wlr_output_layout_impl;

struct wlr_output_layout {
    struct wlr_output_layout_state *state;
    struct wlr_output_layout_impl *impl;

    list_t outputs;
};

struct wlr_output_layout_output {
    struct wlr_output *output;
    int x, y;
};

void wlr_output_layout_add(struct wlr_output_layout *layout,
    struct wlr_output *output, int x, int y);

void wlr_output_layout_move(struct wlr_output_layout *layout,
    struct wlr_output *output, int x, int y);

void wlr_output_layout_remove(struct wlr_output_layout *layout,
    struct wlr_output *output);

/**
 * Given x and y as pointers to global coordinates, adjusts them to local output
 * coordinates relative to the given reference output.
 */
void wlr_output_layout_output_coords(struct wlr_output_layout *layout,
    struct wlr_output *reference, int *x, int *y);

/**
 * Finds the next output in the given direction.
 * x and y should each be 1, 0, or -1.
 */
struct wlr_output *wlr_output_layout_output_towards(struct wlr_output_layout *layout,
    struct wlr_output *output, int x, int y);

We could use wlr_output_layout_intersections during output_frame to find each wayland surface that needs to be rendered to this output. This would also make output mirroring just werk.

Also: kde_output_layout_protocol_attach(kde_ol_ref, output_layout)

wlr_cursor

This would represent an individual cursor (as in ), which might have one or more input devices attached.

struct wlr_cursor_state *;
struct wlr_cursor_impl *;

struct wlr_cursor {
    struct wlr_cursor_state *state;
    struct wlr_cursor_impl *impl;
    int x, y;

    struct {
        struct wl_signal motion;
    } events;
};

/**
 * Attaches this input device to this cursor. The input device must be one of:
 *
 * - WLR_INPUT_DEVICE_POINTER
 * - WLR_INPUT_DEVICE_TOUCH
 * - WLR_INPUT_DEVICE_TABLET_TOOL
 */
void wlr_cursor_attach_input_device(struct wlr_cursor *cur,
    struct wlr_input_device *dev);

void wlr_cursor_detach_input_device(struct wlr_cursor *cur,
    struct wlr_input_device *dev);

/**
 * Uses the given layout to establish the boundaries and movement semantics of
 * this cursor. Cursors without an output layout allow infinite movement in any
 * direction and do not support absolute input events.
 */
void wlr_cursor_attach_output_layout(struct wlr_cursor *cur,
    struct wlr_output_layout *l);

/**
 * Attaches this cursor to the given output, which must be among the outputs in
 * the current output_layout for this cursor. This call is invalid for a cursor
 * without an associated output layout.
 */
void wlr_cursor_map_to_output(struct wlr_cursor *cur, struct wlr_output *output);

/**
 * Maps all input from a specific input device to a given output. The input
 * device must be attached to this cursor and the output must be among the
 * outputs in the attached output layout.
 */
void wlr_cursor_map_input_to_output(struct wlr_cursor *cur,
    struct wlr_input_device *dev, struct wlr_output *output);

/**
 * Maps this cursor to an arbitrary region on the associated wlr_output_layout.
 */
void wlr_cursor_map_to_region(struct wlr_cursor *cur, struct wlr_geometry *geo);

/**
 * Maps inputs from this input device to an arbitrary region on the associated
 * wlr_output_layout.
 */
void wlr_cursor_map_input_to_region(struct wlr_cursor *cur,
    struct wlr_input_device *dev, struct wlr_geometry *geo);

This should allow you to attach several devices to one cursor, have several cursors at once, map one input device to multiple cursors, etc

GLES2 support

I recently tried using wlroots on my laptop with an Intel iGPU (i5-520M is the CPU, not really sure what the iGPU name is), and it currently doesn't work.
It turns out this hardware doesn't support GLES 3, and only goes up as high as GLES 2.
While this laptop is getting on a bit in terms of age, it would be nice for wlroots to be able to support older hardware.

So I think we should either downgrade the current renderer to GLES 2 or create a separate GLES 2 fallback when we can't load GLES 3.

Design a security interface

In #139 the issue of security/privacy sensitive protocol implementation in wlroots came up.

I can see a few ways where a hook like this could sit, with different advantages.

  • Compile time options
  • Config options (user enables/disables for entire compositor)
  • Expose the interface selectivly to clients
  • Ask the compositor on first/binding request
  • Ask the compositor in every request

Compile option

👍 Should be easy to implement
👉 "static" in the library
👎 very coarse
👎 May surprise compositors when a new option is enabled by default

Config option

👍 Currently implemented from what I see
👎 very coarse

Expose the interface selectivly to clients

libwayland has the wl_display_set_global_filter which allows wlroots to filter which globals are exported to which client.
I think the best way to go would be to add callbacks into the manager objects, which can be used for compositor interaction and default to not expose when the callback is not set.
If the function was exposed to a compositor as is the compositor would have to either use a blacklist or know about all unproblematic globals to allow them.
The blacklist may be viable if the approach to let the compositor create a manager object for each protocol.
👍 Nicely grained control on compositor side
👍 Supports the "get pid -> check exe" flow sway has
👉 Should not be terribly hard to implement

Ask on first/binding request

Call into the compositor when the first request is sent (for e.g. screenshooter) or when an object required for other calls in the protocol is requested.

This is similar to the selective exposing IMO. But I like the selective expose more, because it won't confuse an application that expects to be allowed to use some api when it exists.

Ask the compositor on every request

👍 Very fine grained (timing), could allow e.g. no screenshots when banking application is running
👍 Very fine grained (api), this could be used by a compositor to allow parts of a single (big) protocol to a client
👎 Compositor has to fully understand protocol
👎 Clients may not expect to be denied access and act up (or wlroots emulates responses)


I think the best approach would be to selectivly expose interfaces to clients and provide callbacks for the more complex protocols to allow veto-ing on single requests.

(sorry for the emoji spam, github turned my +/- list into listings :( )
Edit: Changed the interface idea for selective exposing after looking at libwayland api

Also Edit:
If one of the modes that can deny access to functions which are exposed to applications is used, should wlroots act like it worked, or try to tell the client it did not?
E.g. give a client a 600x400 black screen when it denies to take a screenshot

Gdk can't find seats

A basic gtk window test on the compositor example fails for me with:

(gtk-test:16551): Gdk-CRITICAL **: gdk_seat_get_keyboard: assertion 'GDK_IS_SEAT (seat)' failed

Try this basic Gdk seat test:

#!/usr/bin/env python3

import gi
gi.require_version('Gdk', '3.0')
from gi.repository import Gdk

DISPLAY='wayland-1'

display = Gdk.Display().open(DISPLAY)
seat = display.get_default_seat()
seats = display.list_seats()

print(seat)
print(seats)

You'll see None as seat and an empty list as seats.

This returns seats on both weston and sway.

wlroots status

Planned and completed features, loosely sorted by priority:

  • Backends
    • DRM
      • Hotplugging (PLEASE TEST - THAT MEANS YOU, GITHUB ISSUE READER)
      • Legacy modesetting
      • Atomic modesetting
      • DPMS
      • Rotation
      • Hardware cursor
      • DisplayPort MST - need additional hardware - #171
      • Multi GPU
        • Throw pixels over the fence
        • Specify main GPU
        • Multi-GPU rendering
        • Switch main GPU at runtime
    • libinput
      • Keyboards
        • Events
        • Key maps
        • LEDs
      • Pointers
      • Touch
        • Get mapped output from udev doesn't work on my hardware
      • Tablet tool
      • Tablet pad
      • Gesture
      • Switch
    • Wayland
      • Output
        • Multiple outputs
        • Rotation
      • Input devices
    • X11
    • RDP
    • fbdev
    • headless
  • Session
    • udev
      • Multi GPU
    • logind
      • elogind
      • VT switching
      • Multi GPU
    • Direct (forking)
      • VT switching
      • fork+setuid
      • Multi GPU
  • Wayland
    • wl_output
    • wl_compositor
      • wl_surface
      • wl_region
    • wl_shm
    • wl_drm
    • wl_shell
      • wl_shell_surface
    • wl_subsurface
    • wl_seat
      • wl_keyboard
        • key repeat
      • wl_pointer
      • wl_touch
      • Multi-seat
    • Extra protocols
      • xdg-shell v6
        • surface
          • toplevel
          • popup
        • positioner
      • xdg-shell v5
      • xdg-shell
      • gamma-control (orbital)
      • screenshooter (weston)
      • server-decoration (kde)
      • layer-shell (wlroots)
      • input-inhibitor (wlroots)
      • input-method
      • pointer-constraints
      • presentation-time
      • linux-dmabuf
      • viewporter
      • xwayland-keyboard-grab
      • relative-pointer
      • xdg-foreign
      • xdg-output
      • tablet
      • idle-inhibit
      • input-timestamps
      • keyboard-shortcuts-inhibit
      • text-input
      • pointer-gestures
      • fullscreen-shell
      • idle
      • gtk-primary-clipboard
        • Sync with Xwayland
    • clipboard
    • drag and drop
  • wlroots features
    • wlr_cursor
    • wlr_xcursor
    • wlr_output_layout
      • Output rotation
      • Output mirroring
      • Output damage
  • Scaling (hidpi)
    • Integral
    • Fractional
  • Rendering
    • Primitives
      • Textured quads
      • Colored quads
      • Colored ellipses
    • Pixman
  • XWayland
    • Initialization
    • Clipboard sync
    • Drag and drop
    • Window management utilities
  • Documentation ¯\_(ツ)_/¯

Cache surface dimensions on surface.attach

According to the spec, when surface.attach is called in the wl_surface interface implementation,

The new size of the surface is calculated based on the buffer size transformed by the inverse buffer_transform and the inverse buffer_scale.

Right now this calculation is done on surface.commit but it should be moved.

Code consistency

Jumping around the code a bit, I can see a few different styles for how different things are handled, particularly error messages, and how certain situations are handled.
These currently aren't covered by CONTRIBUTING.md, so I think we should expand it.

Error Messages

There are several different formats being used, ranging from "Cannot X, reason", "Failed to X: reason", "X failed: reason", etc.
We should mandate that a single style is used. More use of wlr_log_errno (where appropriate) would help.

Assertions

There are a few non-NULL asserts around. We should use them more consistently, at least over the public API.
On a related note, any "destruction" function should be able to accept a NULL pointer and exit gracefully, which simplifies error handling a lot.

Function names

We seem to have functions named *_init, *_create, *_finish, *_destroy. While it's mostly like this already (but not fully), we should document that init/finish should NOT handle allocations, and create/destroy do.

Performance issues

I get some pretty bad stuttering with mpv playing 1080p video on the example compositor using any backend. We should profile this and figure it out.

Finish moving wayland components from example into wlroots

examples/compositor/wl_{compositor,shell}.c -> types/wlc_{compositor,shell}.c

I've decided against making the user implement all of these themselves. These are simple state containers and putting them in wlroots is not a big deal. I've already performed this move for xdg-shell, check out 62d8b25 for an idea of how (if you can read around all the meson changes).

`Atomic commit failed: Invalid argument` when trying to set Output Mode

I've been playing with Haskell bindings to wlroots and tried to reimplement the rotation example as a test.

When I try to run my test, I get an error: [backend/drm/drm-atomic.c:55] Atomic commit failed: Invalid argument

Full log: http://lpaste.net/5837658220885180416
ltrace -e "@libwlroots.so*": http://lpaste.net/6218130441421979648
dmesg | grep drm: http://lpaste.net/6845711118548074496

I'm running this on an i3 2350M which has an intel HD 3000

Code is currently not public, but I can easily make it public if anyone wants to have a look at it.

EDIT: Totally forgot, the error happens when I call into wlr_output_set_mode in the handler for the output_add signal (logic taken from https://github.com/SirCmpwn/wlroots/blob/master/examples/shared.c#L590)

Build fails

$ git clone https://github.com/SirCmpwn/wlroots.git
$ cd wlroots
$ meson build

The Meson build system
Version: 0.40.1
Source dir: /opt/wlroots
Build dir: /opt/wlroots/build
Build type: native build
Project name: wlroots
Native c compiler: cc (gcc 6.4.0)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.28)
Native dependency wayland-server found: YES 1.13.0
Native dependency wayland-client found: YES 1.13.0
Native dependency wayland-egl found: YES 17.0.6
Native dependency wayland-protocols found: YES 1.7
Native dependency egl found: YES 17.0.6
Native dependency glesv2 found: YES 17.0.6
Native dependency libdrm found: YES 2.4.80
Native dependency gbm found: YES 17.0.6
Native dependency libinput found: YES 1.8.1
Native dependency xkbcommon found: YES 0.7.1
Native dependency libudev found: YES 220
Native dependency pixman-1 found: YES 0.34.0
Native dependency xcb found: YES 1.12
Native dependency xcb-composite found: YES 1.12
Native dependency libcap found: YES 2.24
Dependency libsystemd found: NO
Library m found: YES
Program wayland-scanner found: YES (/usr/bin/wayland-scanner)
Build targets in project: 16

$ ninja -C build

ninja: Entering directory `build'
[21/94] Compiling c object 'backend/wlr_backend@sta/drm_drm-util.c.o'
FAILED: backend/wlr_backend@sta/drm_drm-util.c.o 
cc  '-Ibackend/wlr_backend@sta' '-Ibackend' '-I../backend' '-I../include' '-I/usr/include/libdrm' '-fdiagnostics-color=always' '-pipe' '-D_FILE_OFFSET_BITS=64' '-Wall' '-Winvalid-pch' '-Wextra' '-Werror' '-std=c11' '-O0' '-g' '-Wno-unused-parameter' '-DWLR_SRC_DIR="/opt/wlroots"' '-DHAS_LIBCAP' '-fPIC' '-MMD' '-MQ' 'backend/wlr_backend@sta/drm_drm-util.c.o' '-MF' 'backend/wlr_backend@sta/drm_drm-util.c.o.d' -o 'backend/wlr_backend@sta/drm_drm-util.c.o' -c ../backend/drm/drm-util.c
../backend/drm/drm-util.c: In function ‘get_fb_for_bo’:
../backend/drm/drm-util.c:160:25: error: implicit declaration of function ‘gbm_bo_get_offset’ [-Werror=implicit-function-declaration]
  uint32_t offsets[4] = {gbm_bo_get_offset(bo, 0)};
                         ^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
[26/94] Compiling c object 'backend/wlr_backend@sta/libinput_tablet_pad.c.o'
ninja: build stopped: subcommand failed.

Mesa version: 17.0.6. This is on Gentoo Linux.

VT switching hangs wlroots

With the simple compositor, I can switch VT to another one, but when I try to switch back, the compositor hangs.

Log:

==2695== Memcheck, a memory error detector
==2695== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2695== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2695== Command: ./bin/simple
==2695== 
2017-07-24 20:31:14 - [session/logind.c:350] Successfully loaded logind session
2017-07-24 20:31:14 - [backend/udev.c:195] Successfully initialized udev
2017-07-24 20:31:14 - [backend/drm/backend.c:84] Initalizing DRM backend for /dev/dri/card0 (i915)
2017-07-24 20:31:14 - [backend/egl.c:150] Using EGL 1.4
2017-07-24 20:31:14 - [backend/egl.c:152] Supported EGL extensions: EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_WL_bind_wayland_display 
2017-07-24 20:31:14 - [backend/egl.c:153] Using OpenGL ES 3.2 Mesa 17.1.5
2017-07-24 20:31:14 - [backend/egl.c:154] Supported OpenGL ES extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_half_float GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_OES_viewport_array GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_robustness GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_robustness GL_KHR_texture_compression_astc_ldr GL_OES_depth_texture_cube_map GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_separate_shader_objects GL_EXT_shader_framebuffer_fetch GL_EXT_shader_integer_mix GL_EXT_tessellation_point_size GL_EXT_tessellation_shader GL_INTEL_conservative_rasterization GL_INTEL_performance_query GL_ANDROID_extension_pack_es31a GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_copy_image GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_gpu_shader5 GL_EXT_polygon_offset_clamp GL_EXT_primitive_bounding_box GL_EXT_shader_io_blocks GL_EXT_texture_border_clamp GL_EXT_texture_buffer GL_EXT_texture_cube_map_array GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_KHR_context_flush_control GL_KHR_robust_buffer_access_behavior GL_NV_image_formats GL_OES_copy_image GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_gpu_shader5 GL_OES_primitive_bounding_box GL_OES_sample_shading GL_OES_sample_variables GL_OES_shader_io_blocks GL_OES_shader_multisample_interpolation GL_OES_tessellation_point_size GL_OES_tessellation_shader GL_OES_texture_border_clamp GL_OES_texture_buffer GL_OES_texture_cube_map_array GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array GL_EXT_blend_func_extended GL_EXT_buffer_storage GL_EXT_geometry_point_size GL_EXT_geometry_shader GL_EXT_shader_samples_identical GL_KHR_texture_compression_astc_sliced_3d GL_OES_geometry_point_size GL_OES_geometry_shader GL_OES_shader_image_atomic GL_EXT_clip_cull_distance GL_MESA_shader_integer_functions 
2017-07-24 20:31:14 - [examples/shared.c:488] Running compositor on wayland display 'wayland-0'
2017-07-24 20:31:14 - [backend/libinput/backend.c:46] Initializing libinput
2017-07-24 20:31:15 - [backend/libinput/backend.c:76] libinput sucessfully initialized
2017-07-24 20:31:15 - [backend/drm/drm.c:505] Scanning DRM connectors
2017-07-24 20:31:15 - [backend/drm/drm.c:582] Found display 'eDP-1'
2017-07-24 20:31:15 - [backend/drm/drm.c:592] 'eDP-1' connected
2017-07-24 20:31:15 - [backend/drm/drm.c:593] Detected modes:
2017-07-24 20:31:15 - [backend/drm/drm.c:607]   3840@2160@60000
2017-07-24 20:31:15 - [backend/drm/drm.c:607]   3840@2160@47999
2017-07-24 20:31:15 - [backend/drm/drm.c:613] Sending modesetting signal for 'eDP-1'
2017-07-24 20:31:15 - [examples/shared.c:401] Output 'eDP-1' added
2017-07-24 20:31:15 - [examples/shared.c:403] Unknown  344mm x 194mm
2017-07-24 20:31:15 - [backend/drm/drm.c:226] Modesetting 'eDP-1' with '3840x2160@60000 mHz'
2017-07-24 20:31:16 - [backend/drm/drm.c:582] Found display 'HDMI-A-1'
2017-07-24 20:31:16 - [backend/drm/drm.c:592] 'HDMI-A-1' connected
2017-07-24 20:31:16 - [backend/drm/drm.c:593] Detected modes:
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   1920@1080@59934
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   1600@1200@60000
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   1680@1050@59883
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   1280@1024@60020
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   1440@900@59901
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   1280@960@60000
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   1280@800@59910
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   1024@768@60004
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   800@600@60317
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   800@600@56250
2017-07-24 20:31:16 - [backend/drm/drm.c:607]   640@480@59940
2017-07-24 20:31:16 - [backend/drm/drm.c:613] Sending modesetting signal for 'HDMI-A-1'
2017-07-24 20:31:16 - [examples/shared.c:401] Output 'HDMI-A-1' added
2017-07-24 20:31:16 - [examples/shared.c:403] Samsung Electric Company SyncMaster 477mm x 268mm
2017-07-24 20:31:16 - [backend/drm/drm.c:226] Modesetting 'HDMI-A-1' with '1920x1080@59934 mHz'
2017-07-24 20:31:17 - [backend/libinput/events.c:66] Added Power Button [0:1]
2017-07-24 20:31:17 - [backend/libinput/events.c:66] Added Video Bus [0:6]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added Video Bus [0:6]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added Power Button [0:1]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added Lid Switch [0:5]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added Sleep Button [0:3]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added CM Storm Coolermaster Novatouch TKL [9494:39]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added CM Storm Coolermaster Novatouch TKL [9494:39]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added Razer Razer DeathAdder 2013 [5426:55]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added Razer Razer DeathAdder 2013 [5426:55]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added Razer Razer DeathAdder 2013 [5426:55]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added Integrated_Webcam_HD [7119:11146]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added G2Touch Multi-Touch by G2TSP [10900:21217]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added ELAN1010:00 04F3:3012 Touchpad [1267:12306]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added HDA Intel PCH Headphone Mic [0:0]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added HDA Intel PCH HDMI/DP,pcm=3 [0:0]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added HDA Intel PCH HDMI/DP,pcm=7 [0:0]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added HDA Intel PCH HDMI/DP,pcm=8 [0:0]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added HDA Intel PCH HDMI/DP,pcm=9 [0:0]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added HDA Intel PCH HDMI/DP,pcm=10 [0:0]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added AT Translated Set 2 keyboard [1:1]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added ETPS/2 Elantech Touchpad [2:14]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added DELL Wireless hotkeys [0:0]
2017-07-24 20:31:18 - [backend/libinput/events.c:66] Added Dell WMI hotkeys [0:0]
2017-07-24 20:31:18 - [examples/shared.c:40] Key event: Control_L pressed
2017-07-24 20:31:18 - [examples/shared.c:40] Key event: Alt_L pressed
2017-07-24 20:31:18 - [examples/shared.c:40] Key event: XF86Switch_VT_1 pressed
2017-07-24 20:31:18 - [examples/shared.c:40] Key event: XF86Switch_VT_1 released
2017-07-24 20:31:18 - [examples/shared.c:40] Key event: Alt_L released
2017-07-24 20:31:18 - [examples/shared.c:40] Key event: Control_L released
2017-07-24 20:31:19 - [examples/shared.c:40] Key event: F1 pressed
==2695== 
==2695== Process terminating with default action of signal 15 (SIGTERM)
==2695==    at 0x67400D3: __epoll_wait_nocancel (in /usr/lib64/libc-2.25.so)
==2695==    by 0x601EC22: wl_event_loop_dispatch (in /usr/lib64/libwayland-server.so.0.1.0)
==2695==    by 0x601D499: wl_display_run (in /usr/lib64/libwayland-server.so.0.1.0)
==2695==    by 0x40AF13: compositor_run (in /home/tony/projects/wlroots/build/bin/simple)
==2695==    by 0x4095E2: main (in /home/tony/projects/wlroots/build/bin/simple)
==2695== 
==2695== HEAP SUMMARY:
==2695==     in use at exit: 3,624,273 bytes in 22,021 blocks
==2695==   total heap usage: 173,013 allocs, 150,992 frees, 15,318,363 bytes allocated
==2695== 
==2695== LEAK SUMMARY:
==2695==    definitely lost: 98,952 bytes in 15 blocks
==2695==    indirectly lost: 0 bytes in 0 blocks
==2695==      possibly lost: 2,577,001 bytes in 18,453 blocks
==2695==    still reachable: 948,320 bytes in 3,553 blocks
==2695==                       of which reachable via heuristic:
==2695==                         newarray           : 1,536 bytes in 16 blocks
==2695==         suppressed: 0 bytes in 0 blocks
==2695== Rerun with --leak-check=full to see details of leaked memory
==2695== 
==2695== For counts of detected and suppressed errors, rerun with: -v
==2695== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

elogind support

I noticed Cloudef/wlc#279 and we could easily do that as well.
I don't want to blindly add code I can't test, so if someone on a non-systemd system could try this and see if it doesn't break anything, that would be great.

[Proposal] Remove wlr-render, replace with cairo

I was looking around the cairo headers lately, and I found out that cairo can render to GL surfaces (using GLESv2) and create it from EGLDisplays and EGLSurfaces. Their documentation seems to be pretty old and doesn't contain the functions, but you can find them in <cairo/cairo-gl.h>.

I figured instead of having to do anything ourselves and try to design some drawing API, we just tell the user to use this. Cairo can seem to do all of the transformations required, and already is used by sway and probably most wayland compositors.

We don't even need to explicitly support cairo or have it as a dependency (excluding the examples): as long as we expose the EGLDisplay and EGLSurface (which I'm sure we would do anyway), the user can make their own cairo surface or do whatever the hell they want (use some other drawing API, roll their own GL renderer, etc.).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.