On Monday, May 8, 2023, Ben Westover wrote:
> Is this something I can fix, or does modern Xorg just need more VRAM?
try 640x480 and/or 16bpp.
l.
--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Hi!
On Sun, 2023-05-07 at 20:20 -0400, Ben Westover wrote:
> Hello,
>
> On 5/7/23 3:14 AM, Paul Wise wrote:
> > If you add a return statement like this, does that fix the crash?
> >
> > /* non-x86 platform */
> > if (!info->VBIOS) {
> > otypes[0] = OUTPUT_VGA;
> >
On Sun, 2023-05-07 at 20:20 -0400, Ben Westover wrote:
...
> (EE) AddScreen/ScreenInit failed for driver 0
>
> Is this something I can fix, or does modern Xorg just need more VRAM?
I don't know enough about the Xorg codebase to answer this.
It would be a good idea to ask on the upstream
Hello,
On 5/7/23 3:14 AM, Paul Wise wrote:
If you add a return statement like this, does that fix the crash?
/* non-x86 platform */
if (!info->VBIOS) {
otypes[0] = OUTPUT_VGA;
return;
}
Yes, it no longer segfaults. It goes past the point where it previously
On Sat, 2023-05-06 at 16:56 -0400, Ben Westover wrote:
> (gdb) print info
> $1 = (R128InfoPtr) 0x776ed0
> (gdb) print info.VBIOS
> $2 = (uint8_t *) 0x0
If you add a return statement like this, does that fix the crash?
/* non-x86 platform */
if (!info->VBIOS) {
otypes[0] =
On 4/18/23 10:44 PM, Paul Wise wrote:
These are the macro definitions.
#define R128_BIOS8(v) ((info->VBIOS[(v)]))
#define R128_BIOS16(v) ((info->VBIOS[(v)]) | \
(info->VBIOS[(v) + 1] << 8))
#define R128_BIOS32(v) ((info->VBIOS[(v)]) | \
On Tue, 2023-04-18 at 09:42 +0100, Luke Kenneth Casson Leighton wrote:
> On Tuesday, April 18, 2023, Ben Westover wrote:
> > /* non-x86 platform */
> > if (!info->VBIOS) {
> > otypes[0] = OUTPUT_VGA;
> > }
> >
> > bios_header = R128_BIOS16(0x48);
>
>
On Tuesday, April 18, 2023, Ben Westover wrote:
> Hello,
>
> On 4/16/23 10:18 PM, Paul Wise wrote:
>>
>> There is also the case where you launch Xorg via gdb and then run it.
>>
>> $ gdb `which Xorg`
>> (gdb) run
>> (gdb) bt full
>
> Perfect! I was able to get a full backtrace, which
Hello,
On 4/16/23 10:18 PM, Paul Wise wrote:
There is also the case where you launch Xorg via gdb and then run it.
$ gdb `which Xorg`
(gdb) run
(gdb) bt full
Perfect! I was able to get a full backtrace, which is attached. Here's
the part that I think is important:
Program
On Sun, 2023-04-16 at 15:08 -0400, Ben Westover wrote:
> I'm probably doing something wrong (never used gdb before), but Xorg
> closes almost instantly after I run it so there's not enough time to
> launch gdb before it's already segfaulted. It sounds like these tips are
> for when Xorg
Hi,
On 4/15/23 10:56 PM, Paul Wise wrote:
I think you will need to do some debugging, there are some tips here:
https://x.org/wiki/Development/Documentation/ServerDebugging/
I'm probably doing something wrong (never used gdb before), but Xorg
closes almost instantly after I run it so
On Sat, 2023-04-15 at 15:46 -0400, Ben Westover wrote:
> My system is up to date as of April 15, 2023; I'm running kernel
> 6.1.0-7-powerpc with Mesa 22.3.6. Does anyone how to fix this problem?
I think you will need to do some debugging, there are some tips here:
Hello,
I have an iMac G3 with a Rage 128 Pro and 1 GB of RAM. I tried to
install and run Xfce4, but Xorg segfaults when I try to start it.
The full Xorg log is attached, but here is the backtrace at the end:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x240) [0xac4a60]
(EE) 1:
13 matches
Mail list logo
