On both DragonFlyBSD and FreeBSD the vgapci driver is always attach to the device, so we should not dismiss devices based on attached drivers on these platforms.
Signed-off-by: b-aaz <b-aazbsd@proton.me>
The old code checked for whether or not files matching
/dev/fb* or /dev/dri/card* were present on a system.
This is wrong for multiple reasons.
Vesa works fine alongside a framebuffer driver.
Testing whether a device file exists or not is not
enough to detarmine that a driver is present, those
device files should also be able to be opened.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
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>
Reported by gcc 14.1:
vesa.c: In function ‘VESAGetRec’:
vesa.c:285:46: warning: ‘calloc’ sizes specified with ‘sizeof’ in the
earlier argument and not in the later argument [-Wcalloc-transposed-args]
285 | pScrn->driverPrivate = calloc(sizeof(VESARec), 1);
| ^~~~~~~
vesa.c:285:46: note: earlier argument should specify number of elements,
later size of each element
vesa.c: In function ‘VESASetModeParameters’:
vesa.c:300:33: warning: ‘calloc’ sizes specified with ‘sizeof’ in the
earlier argument and not in the later argument [-Wcalloc-transposed-args]
300 | data->block = calloc(sizeof(VbeCRTCInfoBlock), 1);
| ^~~~~~~~~~~~~~~~
vesa.c:300:33: note: earlier argument should specify number of elements,
later size of each element
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/driver/xf86-video-vesa/-/merge_requests/11>
The Xorg headers provide their own versions of strlcat, strlcpy, and
timingsafe_memcmp for platforms that don't have them in libc yet, but
rely on configure to set HAVE_* defines to determine if they should be
defined in the headers.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
AC_PROG_LIBTOOL was replaced by LT_INIT in libtool 2 in 2008,
so it's time to rely on it.
Clears autoconf warnings:
configure.ac:44: warning: The macro 'AC_PROG_LIBTOOL' is obsolete.
configure.ac:44: You should run autoupdate.
aclocal.m4:3515: AC_PROG_LIBTOOL is expanded from...
configure.ac:44: the top level
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The simpledrm driver, introduced in kernel 5.14,
can replace efifb to provide the efi framebuffer.
This fixes a bug on Fedora 36 (first version to use simpledrm driver):
https://bugzilla.redhat.com/show_bug.cgi?id=2074789
v2: check for framebuffer or dri devices instead of efi framebuffer interface.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Found by cppcheck:
src/vesa.c:356:11: style: Redundant initialization for 'pVesa'. The initialized value is overwritten before it is read. [redundantInitialization]
pVesa = VESAGetRec(pScrn);
^
src/vesa.c:350:19: note: pVesa is initialized
VESAPtr pVesa = VESAGetRec(pScrn);
^
src/vesa.c:356:11: note: pVesa is overwritten
pVesa = VESAGetRec(pScrn);
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
vesa.c: In function ‘VESADGASetMode’:
vesa.c:1790:9: warning: unused variable ‘scrnIdx’ [-Wunused-variable]
int scrnIdx = pScrn->pScreen->myNum;
^~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Device memory is the same domain as host memory, in this case, so the
shadow just introduces more memcpy.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Prior to kernel v3.12, the efi framebuffer driver was named "efifb".
This cause problem on RHEL 7 as the base kernel is 3.10.
"efi-framebuffer.0" was added by commit 2645e0aa for that reason
(don't run on UEFI machine).
The change from "efifb" to "efi-framebuffer" was done with commit
e6816a8 in the kernel
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
[ofourdan: updated commit message with commit references]
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
We're preferring depth 24 even if that means 24bpp. Newer servers don't
support 24bpp anymore, and even for old servers it's suboptimal. Change
the heuristic to only try 24bpp if the alternative is pseudocolor.
Fixes: xorg/driver/xf86-video-vesa#3
No possible good can come of this.
v2: Check for .../efi-framebuffer.0 ("is there an EFI framebuffer")
instead of /sys/firmware/efi ("is this an EFI machine"). Suggested by
Peter Jones.
Reviewed-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
I ported vesa to use the VBE service back in:
commit 55f585a15f
Author: Adam Jackson <ajax@redhat.com>
Date: Fri Sep 18 17:02:16 2009 -0400
Use VBE palette load, not VGA banging.
I'm reasonably sure that worked on all the hardware I had handy at the
time. But it doesn't work in seabios, which means 8bpp is broken under
qemu.
We query this API early in initialization, and if it fails ->savedPal
will be NULL, so use that as the hint to fall back to VGA banging.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
