similar to: [ANNOUNCE] xf86-video-vesa 1.2.1

This release rolls up a few minor bug fixes since 2.4.0. We now refuse to run on machines with UEFI firmware (on Linux only, patches welcome for other OSes) since it won't work in the general case and you probably have a kernel framebuffer driver running already. We also only attempt to use 24bpp if the alternative would be pseudocolor, but note that since xserver 1.20 24bpp will not work at

Nothing terribly exciting, but enough bug fixes to justify a release. Adam Jackson (4): Don't build old probe method on sufficiently new servers Fall back to VGA if the palette API isn't supported Use VBEFreeVBEInfo not free vesa 2.4.0 Emil Velikov (1): autogen.sh: use quoted string variables Ian Lepore (1): Honor Option "NoDDC" correctly

Minor update to fix PanelID support. The minimum xserver version is now 1.6; if you haven't updated your xserver in the last six years, now would be a good time. Adam Jackson (3): configure: Drop PanelID test Don't include deprecated xf86PciInfo.h vesa 2.3.4 Alan Coopersmith (1): Raise required version of xorg-server to >= 1.6 git tag: xf86-video-vesa-2.3.4

Aaron Plattner (1): Don't disable FB access when it's already disabled. Adam Jackson (9): Remove all trace of mfb Bug #10004: Fix palette initialization in 8bpp modes. Fix boolean inversion in VBE screen clear. Remove some useless module loading cruft. Prefer a more modern depth/bpp selection. Add semi-reasonable mode validation. Clean up

Dear all, The background is that I'm trying to fix this bug in the geometry package: https://r-forge.r-project.org/tracker/index.php?func=detail&aid=1993&group_id=1149&atid=4552 Boiled down, the problem is that there exists at least one matrix X for which det(X) != 0 and for which solve(X) fails giving the error "system is computationally singular: reciprocal condition

I maintain the geometry package, which integrates the Qhull C library (http://qhull.org) into R. The Qhull function I hook into requires an open FILE handle as one of its arguments. I had set this file handle to stdout, but now R check NOTEs the presence of stdout, and the CRAN maintainers asked me to get rid of these NOTEs. Including the following defines means the checks are passed on CRAN:

> "H. Peter Anvin" <hpa at zytor.com> writes: > > > On 06/03/2014 02:59 AM, Ady wrote: > > > >> Testing Syslinux 6.03-pre13 in a BIOS 32-bit VM, > >> boot: vesa.c32 > >> Undef symbol FAIL: luaL_checklstring > >> Failed to load COM32 file vesa.c32 > >> boot: > >> > >> Is there a Lua-related issue?

I have noticed anything using ANSI escape sequences to color text does not work if syslinux is in VESA mode. It only works if the \1#, \2#, or \3# are used. This means that libmenu which relies on csprint fails to render colors in VESA mode. I noticed the default color table has a complete table generated at runtime for all VGA color combinations, which csprint also does but from VGA attributes on

On 06/03/2014 02:59 AM, Ady wrote: > Testing Syslinux 6.03-pre13 in a BIOS 32-bit VM, > boot: vesa.c32 > Undef symbol FAIL: luaL_checklstring > Failed to load COM32 file vesa.c32 > boot: > > Is there a Lua-related issue? > > Is vesa.c32 expecting some kind of argument? > luaL_checklstring should be found in liblua.c32. Are you perhaps missing the latter? I

Hi! Recently I've been working with the rest of the X.Org board to try to get X.org access to VESA memberships so that contributors that don't have an employer who is able/willing to join VESA can potentially get access to the various benefits of a VESA membership, such as access to DisplayPort specifications. Since I need to gather a list of interested X.org members, I'd like to know

"H. Peter Anvin" <hpa at zytor.com> writes: > On 06/03/2014 02:59 AM, Ady wrote: > >> Testing Syslinux 6.03-pre13 in a BIOS 32-bit VM, >> boot: vesa.c32 >> Undef symbol FAIL: luaL_checklstring >> Failed to load COM32 file vesa.c32 >> boot: >> >> Is there a Lua-related issue? >> >> Is vesa.c32 expecting some kind of

Jan, List: Is there any way we can compile a kernel to include the VESA Video Modes for 1440x900 resolution so that we can pass grub VGA=867 for 1440x900. This will all me to work in runlevel 3 without the screen resolution being stretched from 1024x768 to 1440x900. The stretch causes everything to be distorted. The necessary VESA modes and numbers are: 1440x900 (dec;

The Vesa driver works fine with CentOS 4.4. I have an NVidia 6200 video adapter. I go to Applications | System Settings | Display | Hardware tab and find my video adapter in the list and set it. The dialog tells me I have to log out for it to take effect, so I duly do that. I then getting a message from a non-graphics screen saying that the attempt to switch to the video adapter failed. When

Testing Syslinux 6.03-pre13 in a BIOS 32-bit VM, boot: vesa.c32 Undef symbol FAIL: luaL_checklstring Failed to load COM32 file vesa.c32 boot: Is there a Lua-related issue? Is vesa.c32 expecting some kind of argument? TIA, Ady.

CentOS Errata and Bugfix Advisory 2011:0973 Upstream details at : https://rhn.redhat.com/errata/RHBA-2011-0973.html The following updated files have been uploaded and are currently syncing to the mirrors: ( md5sum Filename ) i386: e8cacf9146380e2ab36a69034b1b9110 xorg-x11-drv-vesa-1.3.0-8.3.el5.i386.rpm Source: aab44dbb61428ce8010ff2e2725d4c4c xorg-x11-drv-vesa-1.3.0-8.3.el5.src.rpm --

CentOS Errata and Bugfix Advisory 2011:0973 Upstream details at : https://rhn.redhat.com/errata/RHBA-2011-0973.html The following updated files have been uploaded and are currently syncing to the mirrors: ( md5sum Filename ) x86_64: 842b32edb31fa10a8b0cec6855f5eea9 xorg-x11-drv-vesa-1.3.0-8.3.el5.x86_64.rpm Source: aab44dbb61428ce8010ff2e2725d4c4c xorg-x11-drv-vesa-1.3.0-8.3.el5.src.rpm

Subject: Obtain VESA capabilities and attributes of VESA mode Also, move some more common code to dom0_init_screen_info(). This was tested on 2.6.22.1, and only made apply to 2.6.18 without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-08-07/arch/i386/kernel/setup-xen.c =================================================================== ---

Ady <ady-sf at hotmail.com> writes: >> "H. Peter Anvin" <hpa at zytor.com> writes: >> >>> I didn't realize how many modules there are in Lua, and quite frankly >>> not all of them are very well named in the sense that it is clear that >>> they are Lua-related. vesa.c32 is one of those - it is one of several >>> Lua

Hi all, new to this list ;) I have a Lenovo Thinkpad T61. lspci|grep VGA says: 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M (rev a1) I have Slacware64-13.0 and Slackware64-current installed. Nouveau is modularized in all my kernels for -current. A problem arise even if I don't want to use nouveau under X: unless nouveau be blacklisted in

Hi I want to play Duke Nukem 3d, but I need a Vesa driver, but i can't find anyone who want to work. Is there somebody who know something about this problem?????? I have: Windows 2000 Creative Labs RIVA TNT