similar to: boot logo via boot.txt

Hi, the display of LSS16 files from a DISPLAY file (as documented in http://www.syslinux.org/wiki/index.php/SYSLINUX#Display_graphic_from_filename:) seems heavily broken since syslinux has been converted from assembler to C. I already discovered one bug in core/include/graphics.h (and core/graphics.c): the pointer VGAFilePtr is of type uint16_t*, but should be plain char*. This bug causes the

> Hi, > > the display of LSS16 files from a DISPLAY file (as documented in > http://www.syslinux.org/wiki/index.php/SYSLINUX#Display_graphic_from_filename:) > seems heavily broken since syslinux has been converted from assembler to > C. I already discovered one bug in core/include/graphics.h (and > core/graphics.c): the pointer VGAFilePtr is of type uint16_t*, but > should

getnybble() needs to return four bits at a time from every byte. During rle decode, rows are rounded to an integer number of bytes. The rle length needs to be able to hold values > 255. Signed-off-by: Chas Williams <3chas3 at gmail.com> --- core/graphics.c | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/core/graphics.c

VGAFilePtr is used as a pointer into VGAFileBuf, so it should be the same type. Signed-off-by: Chas Williams <ciwillia at brocade.com> --- com32/elflink/ldlinux/msg.c | 4 ++-- core/graphics.c | 2 +- core/include/graphics.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/com32/elflink/ldlinux/msg.c b/com32/elflink/ldlinux/msg.c index 9ded33e..37cbe71

On Fri, 2015-08-21 at 12:33 -0700, Patrick Masotta wrote: > I think probably this patch is buggy: > > You have redefined VGAFilePtr > > -__export uint16_t *VGAFilePtr; /* Pointer into VGAFileBuf */ > +__export char *VGAFilePtr; /* Pointer into VGAFileBuf */ > > but you did not redefine i.e. > > *VGAFilePtr++ = data; > > Incrementing a

>>>> VGAFilePtr is used as a pointer into VGAFileBuf, so it should be the same type. Signed-off-by: Chas Williams <ciwillia at brocade.com> --- .... <<<< I think probably this patch is buggy: You have redefined VGAFilePtr -__export uint16_t *VGAFilePtr; /* Pointer into VGAFileBuf */ +__export char *VGAFilePtr; /* Pointer into VGAFileBuf */

Inspired by the exchange between Rolf Turner and Wacek Kusnierczyk, I thought I'd clear up for myself the exact relationship among the various sequence concepts in R, including not only generic vectors (lists) and atomic vectors, but also pairlists, factor sequences, date/time sequences, and difftime sequences. I tabulated type of sequence vs. property to see if I could make sense of all

Inspired by the exchange between Rolf Turner and Wacek Kusnierczyk, I thought I'd clear up for myself the exact relationship among the various sequence concepts in R, including not only generic vectors (lists) and atomic vectors, but also pairlists, factor sequences, date/time sequences, and difftime sequences. I tabulated type of sequence vs. property to see if I could make sense of all

The original implementation utilies select(). In Linux select() typically supports up to 1024 file descriptors. This can be a problem when user tries to boot up many guests. Switching to poll() has minimum impact on existing code and has better scalibility. Up to 8192 file descriptors are supported in the current implementation. Signed-off-by: Wei Liu <wei.liu2@citrix.com> ---

>>>> getnybble() needs to return four bits at a time from every byte. During rle decode, rows are rounded to an integer number of bytes. The rle length needs to be able to hold values > 255. Signed-off-by: Chas Williams <3chas3 at gmail.com> <<<< I think this change is also already included in the patch quoted previously by Ady

The following code can be used to convert a 256 color BMP to LSS format for use as a SYSLINUX/ISOLINUX/PXELINUX Splash screen. The bitmap must be LESS than 640 pixels wide (bug) and only uses the first 16 colors. CorelDraw and PhotoShop are good for re-palletizing and dithering. Paul Shebanow pshebanow at iqcorp.com --- Begin Code --- Type RGBColor4 cBlue As Byte cGreen As Byte

From: Matt Fleming <matt.fleming at intel.com> Since we can't use __intcall() for EFI, and since we can now have the ELF module code resolve all our symbols at runtime, we should delete as many references to __intcall() as possible and just access the symbols directly. The most interesting patch is the support for weak symbols. We need to be able to reference derivative-specific

Hello all, This are the latest version of the patches. Lots of things have changed since the last submission. A few of which I remember: - VNC copy / paste works* (* conditions apply) - client vnc copies get propagated to guest port 3 (/dev/vmch3) - guest writes to port 3 (/dev/vmch3) go straight to client's clipboard - sysfs hooks to autodiscover ports - support for 64 ports in this

Hello all, This are the latest version of the patches. Lots of things have changed since the last submission. A few of which I remember: - VNC copy / paste works* (* conditions apply) - client vnc copies get propagated to guest port 3 (/dev/vmch3) - guest writes to port 3 (/dev/vmch3) go straight to client's clipboard - sysfs hooks to autodiscover ports - support for 64 ports in this

While attempting to work on implementing readdir in ISOLINUX, I made it large enough that it overflowed for isolinux-debug. $ make all nasm -O9999 -f elf -g -F stabs -DDATE_STR="'pre11-112-g930881b*'" \ -DHEXDATE="0x49caaf5b" \ -l isolinux.lsr -o isolinux.o isolinux.asm ld -m elf_i386 -T syslinux.ld -M -o isolinux.elf isolinux.o >

Xen patchbot -unstable wrote: ># HG changeset patch ># User cl349@firebug.cl.cam.ac.uk ># Node ID 8fe8a99b1c2a6ea88624546ab625eaa0758e3a17 ># Parent e69cbfee4011da1648718f1f5cbe8dabb956e72a >New console transport and update xenconsoled. >Add a new console interface using a seperate shared page and event channel >instead of passing the console input/output over control

I think my oven is broken, but maybe I have the recipe wrong. I've been trying to utilize the lwIP stack and dmi information to avoid iPXE use. I can do a SYSAPPEND 0x00080 and it shows up in /proc/cmdline after booting the kernel, but tcpdump is not revealing the cookies as described during HTTP calls in the documentation. Trying the magic "SENDCOOKIES" parameter outside of an

Hmm... well adding the __export stopped the "undefined symbol" error from showing up when I add "SENDCOOKIES" in the config, however I'm still not seeing any cookies being sent to my webserver. Any ideas on how to further debug? (if you want to send me the debug compile options privately that's okay too) -----Original Message----- From: H. Peter Anvin [mailto:hpa at

From: Sylvain Gault <sylvain.gault at gmail.com> Hello there, I propose 2 patches that fix two possible stack overflows either when running a COM32 module or when loading a new config file. I didn't find a better way to do this than to use the infamous setjmp/longjmp functions to restore the stack to a previous state. This makes the logic a bit more complex, but the behavior is not

On Wed, 12 Jun, at 11:17:44AM, Gerardo Exequiel Pozzi wrote: > Cool thanks!. Now looks better, but still not work. > > For some reason, "ldlinux.c32" is apparently sent but "Failed to load" > by PXELINUX and few seconds later, dnsmasq shows an error message > "failed sending": Argh! The patch was broken. I missed the new core/path.c file. My bad.