> sna_video.c: In function 'sna_video_init':
> sna_video.c:956:13: error: 'noXvExtension' undeclared (first use in this function); did you mean 'XvExtension'?
> 956 | if (noXvExtension)
> | ^~~~~~~~~~~~~
> | XvExtension
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's really no need to duplicate fd to a trivial sysfs file, neither
any need to explicitly mark it as close-on-exec. There's no locking
whatsoever involved, even parallel writes are fully supported for
sysfs attribute files.
And the way it was done was really weird and fragile: it just brutely
overwrote fd # MAXCLIENTS. The MAXCLIENTS define is internal to the
Xserver, outside of individual driver's concern, and drivers really
shouldn't directly mess with the fd table that way - they have no way
to make sure it's really done right.
Therefore, just drop this all and leave the fd as it is.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Include <sys/select.h> to provide timer_tv. Fixes the missing definition
when sna is enabled and udev is disabled in configure.
Fixes: #10
Signed-off-by: callmetango <callmetango@users.noreply.github.com>
The module directory has changed to a per ABI folder in the xlibre-xserver.
Now the default value of `xorg-module-dir` will be detected from the `moduledir` variable in xorg-server.pc.
Signed-off-by: b-aaz <b-aazbsd.proton.me>
This pipeline builds the driver against the latest Xserver stable
release as well as current master.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add the following forms for issue creation:
* Bug report
* Feature request
* Code change
* Documentation update
* Organizational task
* add issue type selection page on "New Issue" call
* mention Github Discussions and the mailing list where appropriate
Part-of: X11Libre/misc#156
Signed-off-by: callmetango <callmetango@users.noreply.github.com>
The AllocateFontPrivateIndex() is gone from Xserver since about a decade
ago, but the driver doensn't correctly detect it. Since there's really
no need to support an over a decade old Xserver anymore, just drop the
whole detection logic and use xfont2_allocate_font_private_index()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This driver is the only one still using xf86nameCompare() and so
blocking it's removal from Xserver module ABI.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some (non-BSD) platforms don't have <byteswap.h>, so better use the
Xserver's bswap_32() implementation here.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
xnfcalloc is just an alias for XNFcallocarray() that doesn't seem to serve
any practical purpose, so it can go away once all drivers stopped using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
xnfalloc is just an alias for XNFalloc() that doesn't seem to serve
any practical purpose, so it can go away once all drivers stopped using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These are just wrappers for calling input_lock()/input_unlock() and marked
deprecated for quite a while now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Adding a gitlab pipeline building this driver against Xserver major releases
since 1.18, including current master branch, on Debian as well as FreeBSD.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Adding a bunch of common scripts for building xorg drivers on different
platforms (for now Debian and FreeBSD) against different server versions.
Also designed to be executed locally (eg. within a VM), so one doesn't
always have to employ f.d.o gitlab.
For now, these are synced manually across various driver repos, until we've
found a viable solution for a central place.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Xserver includes have explicit pointer types for quite all kind of structs
(at least those used by drivers), which are used all over the Xserver.
Thus it's much cleaner to use those everywhere.
This commit also clears the road to fix a horrible nightmare of hacks just
needed to circumvent naming clashes between Xserver and Xlib (affecting all
DDXes that are painting on another Xserver): we can simply rename Xserver's
own "GC" type to "GCRec" (the usual naming convention here) and so no trouble
with Xlib's "GC" type anymore. Once this has landed, we're free to do that
without breaking this driver.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The Xserver's System() function is a special wrapper for calling a program
(xkbcomp) as an unprivileged user, when the Xserver is running as suid-root.
(which today only needed on a few platforms, eg. Solaris). Therefore it's
not suited for being called by arbitrary drivers.
In this specific context it doesn't even much sense, since it's just used
for checking whether pkexec command is present at all (and just should be
used), while the actual exec'ing of the helper is done directly by fork()
and exec() syscalls.
Thus we can safely use standard system() call instead - clearing the road
for dropping System() from Xserver's public/driver API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
ETIME seems to be missing, so just alias it to ETIMEDOUT
It's just used by internal functions of the tools.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The Xserver has been moved to using pixman for all matrix operations, back in
2008, but left some #define's so drivers still compile. Since 1.5 decades have
passed now, it's time to fix remaining drivers still using the old name, so
we can drop these #define's from the Xserver includes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Let's disable the colorkey whenever we hide the sprite. The colorkey
is a non-standard thing so generic kms clients have no way to disable
it, and the kernel may reject certain otherwise legal things if
colorkeying is left active.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Looks like we're leaking video->bo[index] if the entire
sprite gets clipped. Let's plug that leak.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Currently we're doing a blind memcpy() from a DDXPointRec
into the beginning of a BoxRec. While this apparently works
it's quite dodgy. Get rid of the memcpy() and simply assign
each member by hand.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
gcc-14 complains:
../src/legacy/i810/i810_dri.c:281:48: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
...
Fix them all up via cocci:
@@
expression E1, E2;
type T;
@@
(
- calloc(sizeof(T), E2)
+ calloc(E2, sizeof(T))
|
- calloc(sizeof(E1), E2)
+ calloc(E2, sizeof(E1))
)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Symbols such as XvCreateImage, XvPutImage, XvGetPortAttribute come from
libXv.so. Linking to this dependency directly fixes build errors on
Debian Bookworm against xserver 21.1.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Looks to me like the theoretical max the sprintf()s need
here is about 34+4+9+sizeof(de->d_name) bytes. Let's just
make that 64+sizeof(de->d_name) for simplicity.
This shuts up the compiler:
../src/intel_device.c: In function ‘__intel_open_device__pci’:
../src/intel_device.c:387:60: warning: ‘%s’ directive writing up to 255 bytes into a region of size 247 [-Wformat-overflow=]
387 | sprintf(path + base + 4, "/dev/dri/%s", de->d_name);
| ^~
../src/intel_device.c:387:25: note: ‘sprintf’ output between 10 and 265 bytes into a destination of size 256
387 | sprintf(path + base + 4, "/dev/dri/%s", de->d_name);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/intel_device.c:392:54: warning: ‘/dev’ directive writing 4 bytes into a region of size between 0 and 255 [-Wformat-overflow=]
392 | sprintf(path + base + 3, "/%s/dev", de->d_name);
| ^~~~
../src/intel_device.c:392:25: note: ‘sprintf’ output between 6 and 261 bytes into a destination of size 256
392 | sprintf(path + base + 3, "/%s/dev", de->d_name);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
../src/sna/kgem_debug_gen3.c:1289:50: warning: ‘%03d’ directive writing between 3 and 10 bytes into a region of size 8 [-Wformat-overflow=]
1289 | sprintf(instr_prefix, "PS%03d", instr);
| ^~~~
../src/sna/kgem_debug_gen3.c:1289:47: note: directive argument in the range [0, 1431655764]
1289 | sprintf(instr_prefix, "PS%03d", instr);
| ^~~~~~~~
../src/sna/kgem_debug_gen3.c:1289:25: note: ‘sprintf’ output between 6 and 13 bytes into a destination of size 10
1289 | sprintf(instr_prefix, "PS%03d", instr);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The compiler is utterly wrong here of course since 'instr'
will at most be (0x1ff + 2 - 1) / 3 ~= 170 (though the hardware
defined max is actually only 123). But let's bump the buffer
size a little bit to shut the compiler up.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
../src/sna/kgem_debug_gen2.c:625:5: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration]
625 | const static struct {
| ^~~~~
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Let's the limit the use of hardware pipe numbers to absolutely
the only place where it's needed (MI_SCANLINE_WAIT). Everywhere
else just use the crtc index.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
For consistency with most other code use the kms crtc index
instead of the hardware pipe number where either will do.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Start using the kms crtc index rather than the pipe almost
everywhere. The two numbers could in theory be different
if the hardware has some pipes fused off. Though I think
such non-contiguous fusing won't actually happen on the
hardware generations the driver fully supports.
The places where we must use the kms crtc indexes are
eg. vblank ioctl crtc selection bits, and checks
against in encoder possible_crtcs bitmask.
The only place where we must stick to the hardware pipe
indexing is the MI_SCANLINE_WAIT stuff as there we have to
construct CS packets to be consumed by the hardware itself.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Start using the kms crtc index rather than the pipe almost
everywhere. The two numbers could in theory be different
if the hardware has some pipes fused off. Though I think
such non-contiguous fusing won't actually happen on the
hardware generations the driver fully supports.
The places where using the kms crtc index is the correct
choice have to do with the vblank ioctl crtc selection.
The only place where we must stick to the hardware pipe
indexing is the MI_SCANLINE_WAIT stuff as there we have to
construct CS packets to be consumed by the hardware itself.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The libdrm enum usage is a mess, and modern gcc is unhappy about
the implicit conversions:
../src/sna/sna_present.c:229:26: warning: implicit conversion from ‘enum <anonymous>’ to ‘enum drm_vblank_seq_type’ [-Wenum-conversion]
Just cast to an integer type to silence the warns.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The modparam checks performed by sna_mode_wants_tear_free() don't
generally work when the server is running as a regular user. Hence
we can't rely on them to indicate whether FBC/PSR/etc is enabled.
Also the "Panel Self-Refresh" connector property doesn't actually
exist so we can nuke that part as well. Let's just nuke the whole
thing and assume we want dirtyfb always when tearfree is not enabled.
I'll anyway want to enable FBC by default across the board soonish
so the check wouldn't really buy us much (would just exclude i830
and a few old desktop chipsets which don't have FBC hardware).
Additionally if we don't have working dirtyfb we really should
enable tearfree by default because otherwise we're going to
get horrible lag due to missing frontbuffer flushes.
Without WC mmaps we could in theory rely on the hw gtt tracking
except the kernel no longer differentiates between GTT/WC/CPU
access in its software frontbuffer tracking code so it'll just
deactivate FBC even for a GTT mmap and potentially never re-enable
it due to the missing frontbuffer flush from dirtyfb. So dirtyfb
is always needed.
v2: Rebase due to ppgtt->tear free logic
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Since kernel commit 78d2ad7eb4e1 ("drm/i915/gt: Fix
-EDEADLK handling regression") running out of fences
will result in -ENOBUFS instead of -EDEADLK (the latter
having been stolen by ww mutextes for their internal use).
Adjust the fence dumping to expect either errno value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fix the s/push_options/pop_options/ pragma so that we don't
emit sse2 in the codepaths that run on non-sse2 machines as well.
Seems gcc has become much more aggressive in its sse2 usage
recently and I'm now hitting sse2 instructions in
choose_memcpy_tiled_x() on my non-sse2 P3 machine.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Once we have DRI3 in Mesa i915 driver we can allow DRI3
on gen2/3.
But due to the supposed missing DRI2 fallback with older Mesa
let's only do that if the user explicitly requests it. Note
that when I tried this with modern Mesa that lacks i915 DRI3
support things seemed to fall back to DRI2 just fine, but
better safe than sorry I guess.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
References: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9734
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We need to wait for flip events even when doing async flips,
otherwise the kernel will just hand us -EBUSY if we try to
flip too fast.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Since not all memory ranges can be mapped by userptr, in particular those
passed by XShmAttachFD, we need to validate the userptr before use. We
would ideally want to continue to lazily populate the pages as often the
userptr is created but never used, but preventing an EFAULT later is
more important.
In https://patchwork.freedesktop.org/series/33449/ we provided a more
efficient method for probing the userptr on construction while
preserving the lazy population of gup-pages. For now, always follow
userptr with set-domain.
Reported-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since not just Haswell will enjoy clear-residuals, be very careful
before using a potential context switch from DRI clients.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
