search for: compositors

https://bugs.freedesktop.org/show_bug.cgi?id=97462 Bug ID: 97462 Summary: Graphics deadlock "ILLEGAL_MTHD" in nouveau with mesa version 11.2.2 when visiting Google Maps with firefox 49.0b5 Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All)

https://bugs.freedesktop.org/show_bug.cgi?id=92893 Bug ID: 92893 Summary: NV34: XPresent compositor scrambled Product: xorg Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

On Mon, 28 Apr 2014 14:07:56 -0400 Ilia Mirkin <imirkin at alum.mit.edu> dijo: >On Mon, Apr 28, 2014 at 1:33 AM, John Jason Jordan ><johnxj at comcast.net> wrote: >> On Sun, 27 Apr 2014 23:01:57 -0400 Ilia Mirkin >> <imirkin at alum.mit.edu> dijo: >>>On Sun, Apr 27, 2014 at 10:41 PM, John Jason Jordan >>><johnxj at comcast.net> wrote:

I spent some time this week trying to add support for input transformations to the server. I tried a few different approaches. The patches I've attached are what's currently working best for me. In this approach I allow every window to have it's own root window coordinate space. A window's root window coordinate space is affected by all it's ancestors. Composite clients can

...lly in a good position to service the GLX protocol. However, this situation changes radically under compositing, because the composite manager becomes responsible for all drawing on the screen. When compositing is enabled it might make more sense for the compositor to filter the GLX protocol. Compositors are usually integrated into window managers that redirect substructure requests on non-override_redirect windows. The effective redirection of the GLX protocol would also require the redirection of Window creation and destruction requests on all windows to provide full parity between GLX 1.2 and G...

Hello, I have my work on the nv vpe video decoder in a functional state. In case you didn't know this decoder accelerates mpeg2 video at the idct/mc level. I have verified that it works on nv40 hardware. I believe it works on nv30 hardware (and maybe some earlier hardware), but I cannot verify since I have none. I will reply with patches against the kernel, drm, ddx and mesa for

Hi Lyude! On Wednesday, June 21st, 2023 at 23:56, Lyude Paul <lyude at redhat.com> wrote: > > - if (changed) > > + if (changed == 1) > > + drm_kms_helper_connector_hotplug_event(first_changed_connector); > > + else if (changed > 0) > > drm_kms_helper_hotplug_event(dev); > > I'm curious if you think there might be an advantage to doing this

Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). > This is to allow clients running within VMs to be able to communicate > with a compositor in the host. Clients will use the communication > protocol that the compositor supports, and virtio-gpu will assist with > making buffers available in both

Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). > This is to allow clients running within VMs to be able to communicate > with a compositor in the host. Clients will use the communication > protocol that the compositor supports, and virtio-gpu will assist with > making buffers available in both

https://bugs.freedesktop.org/show_bug.cgi?id=100139 Bug ID: 100139 Summary: [DRI2][PRIME] nouveau driver cannot find any connected connector Product: Mesa Version: 10.3 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component:

https://bugs.freedesktop.org/show_bug.cgi?id=108651 --- Comment #2 from Yuxuan Shui <yshuiv7 at gmail.com> --- compton itself does not have lots of dependencies. Right now all the users experienced this problem seems to be using the i3 window manager, I don't know if this is reproducible with windowmaker. I don't know the mesa version they use, I will ask. But judging that they are

https://bugs.freedesktop.org/show_bug.cgi?id=63192 Pierre Moreau <pierre.morrow at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Component|DRM/other |Driver/nouveau Version|DRI git

This is with 64k page size. Ilia Mirkin schreef op 2020-06-22 19:27: > I suspect screen tearing (as it's usually defined) is to be expected. > Can you take a photo of what you're seeing, since I'm suspecting it's > more than regular screen tearing? > > On Mon, Jun 22, 2020 at 12:08 PM Jeroen Diederen > <jjhdiederen at zonnet.nl> wrote: >>

On 02/05/2018 01:20 PM, Gerd Hoffmann wrote: > Hi, > >>> Why not use virtio-vsock to run the wayland protocol? I don't like >>> the idea to duplicate something with very simliar functionality in >>> virtio-gpu. >> >> The reason for abandoning that approach was the type of objects that >> could be shared via virtio-vsock would be extremely

...e Portal is unsuitable when Xwayland is running in a nested compositor. Xwayland cannot tell whether it's running on a nested compositor and to keep backwards compatibility with Xwayland prior to 23.2.0, Xwayland must now be started with "-enable-ei-portal" to connect to the portal. Compositors (who typically spawn Xwayland rootless) must now pass this option to get the same behaviour as 23.2.x. Finally, Xwayland now uses libbsd-overlay instead of libbsd. Jeffy Chen (1): glamor: xv: Fix invalid accessing of plane attributes for NV12 Jos? Exp?sito (1): xwayland/glamor/gbm:...

Hello, For a long time, I have been creating eps files from R using the following command: dev.copy2eps(file="my.eps") This has worked very well. But recently, the compositor of a journal is complaining that "The eps files would be useable except that they have not converted the type to outlines" Sorry for being vague, but I have no idea what this compositor is talking

Hi, > > Why not use virtio-vsock to run the wayland protocol? I don't like > > the idea to duplicate something with very simliar functionality in > > virtio-gpu. > > The reason for abandoning that approach was the type of objects that > could be shared via virtio-vsock would be extremely limited. Besides > that being potentially confusing to users, it would mean

Hi, > > Why not use virtio-vsock to run the wayland protocol? I don't like > > the idea to duplicate something with very simliar functionality in > > virtio-gpu. > > The reason for abandoning that approach was the type of objects that > could be shared via virtio-vsock would be extremely limited. Besides > that being potentially confusing to users, it would mean

https://bugs.freedesktop.org/show_bug.cgi?id=92863 Bug ID: 92863 Summary: Complete freeze even with NvGrUseFW=1 Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau

Hi All, Duncan, Rolf, Ista, DIrk, Thanks for the suggestions and I tried all of them (as suggested by Duncan, Rolf, Ista and Dirk)... I still get similar error as before while installing 'rgl' package.. I also tried to manually configure "rgl" and got an error message (please see below for the verbatim output). Would highly any further ideas/suggestions! *In my system,