> > > Maybe switching a text console to 16bit with fbset could help me testing
> > > the 1bit console code.
> >
> > For testing, I added the following `null' video mode to /etc/fb.modes:
> >
> > mode "null"
> > geometry 1 1 1 1 0
> > timings 0 0 0 0 0 0 0
> > endmode
> >
> > After t
> > Where can I find the fixed fbtest version?
>
> cvsroot :ext:@linux-fbdev.cvs.sourceforge.net:/cvsroot/linux-fbdev
> module FBdev/utlilities/fbtest
Can't log in as anonymous user there ... I'll pull the code from cvsweb if
needs be.
> > Maybe switching a text console to 16bit with fbset could
Hi Michael,
On Sun, 2 Mar 2008, Michael Schmitz wrote:
> > Finally I managed to get fbset and fbtest (from sf.net CVS) through the
> > network
> > into my virtual Atari. I fixed 2 brown paper bag bugs in fbtest, which now
> > works fine in all modes (interleaved bitplanes at 1/2/4/8 bpp a
Hi Geert,
> Finally I managed to get fbset and fbtest (from sf.net CVS) through the
> network
> into my virtual Atari. I fixed 2 brown paper bag bugs in fbtest, which now
> works fine in all modes (interleaved bitplanes at 1/2/4/8 bpp and packed
> pixels
> at 16 bpp). So in theory, X should wor
> Geert Uytterhoeven wrote:
> > For cfb16 on Falcon I see no direct problems. Perhaps it just failed
> > because DefaultDepth in /etc/X11/xorg.conf defaults to 24 these days?
>
> the problem I faced was that I couldn't *boot* in the 16bit color depth
> so I *thought* I couldn't run X, or something
Hi,
> > AFAIR fix->line_length was not set because encode_fix could be called
> > before the video mode was actually set up. Or maybe because I could not
> > figure out how to derive line_len from the hw pars.
>
> Well, originally fb_fix_screeninfo.line_length didn't exist, and
> applications just
m68k
Subject: Re: Xorg on m68k
Michael Schmitz wrote:
> Hi,
>
>> The text console is broken in 16 bpp, as atafb uses the
>> atafb_iplan2p8* drawing operations for both 8 and 16 bpp. The patch
>> below is a first step to fix this, but it doesn't work yet as the
>>
On Fri, 22 Feb 2008, Michael Schmitz wrote:
> > The text console is broken in 16 bpp, as atafb uses the atafb_iplan2p8*
> > drawing operations for both 8 and 16 bpp. The patch below is a first
> > step to fix this, but it doesn't work yet as the cfb_*() routines need
> > valid numbers in fb_fix_scr
Hi,
> > What would that line_length be, I wonder - just yres*2?
>
> xres*2 is the line_length in bytes, IMHO
Yup, but do we need it in bytes, or pixels?
I'll post a patch as soon as I can test it on ARAnyM.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "uns
Hi Geert,
> The text console is broken in 16 bpp, as atafb uses the atafb_iplan2p8*
> drawing operations for both 8 and 16 bpp. The patch below is a first
> step to fix this, but it doesn't work yet as the cfb_*() routines need
> valid numbers in fb_fix_screeninfo.line_length, which is not set up
Michael Schmitz wrote:
Hi,
The text console is broken in 16 bpp, as atafb uses the atafb_iplan2p8*
drawing operations for both 8 and 16 bpp. The patch below is a first
step to fix this, but it doesn't work yet as the cfb_*() routines need
valid numbers in fb_fix_screeninfo.line_length, which is
Hi,
> The text console is broken in 16 bpp, as atafb uses the atafb_iplan2p8*
> drawing operations for both 8 and 16 bpp. The patch below is a first
> step to fix this, but it doesn't work yet as the cfb_*() routines need
> valid numbers in fb_fix_screeninfo.line_length, which is not set up by ata
On Tue, 19 Feb 2008, Geert Uytterhoeven wrote:
> On Tue, 19 Feb 2008, Petr Stehlik wrote:
> > Petr Stehlik wrote:
> > > Geert Uytterhoeven wrote:
> > > > For cfb16 on Falcon I see no direct problems. Perhaps it just failed
> > > > because DefaultDepth in /etc/X11/xorg.conf defaults to 24 these days
On Thu, 21 Feb 2008, Roman Zippel wrote:
> On Thu, 21 Feb 2008, Geert Uytterhoeven wrote:
> > I tried your suggestion yesterday evening, but it didn't seem to work
> > for me. E.g. when trying to ping .134, I get
> >
> > | $ ping 192.168.3.134
> > | PING 192.168.3.134 (192.168.3.134) 56(84) bytes
Hi,
On Thu, 21 Feb 2008, Geert Uytterhoeven wrote:
> I tried your suggestion yesterday evening, but it didn't seem to work
> for me. E.g. when trying to ping .134, I get
>
> | $ ping 192.168.3.134
> | PING 192.168.3.134 (192.168.3.134) 56(84) bytes of data.
> | ping: sendmsg: Operation not permi
On Thu, 21 Feb 2008, Roman Zippel wrote:
> On Wed, 20 Feb 2008, Petr Stehlik wrote:
> > > > [ETH0]
> > > > Type = ptp
> > > > Tunnel = tap0
> > > > HostIP = 192.168.3.133
> > > > AtariIP = 192.168.3.134
> > > > Netmask = 255.255.255.252
> > > >
> > > > IMO aratapif shouldn't be necessary (I use pr
Hi,
On Wed, 20 Feb 2008, Petr Stehlik wrote:
> > > [ETH0]
> > > Type = ptp
> > > Tunnel = tap0
> > > HostIP = 192.168.3.133
> > > AtariIP = 192.168.3.134
> > > Netmask = 255.255.255.252
> > >
> > > IMO aratapif shouldn't be necessary (I use pretty much the same setup
> > > with
> > > qemu), bu
Hi,
On Wed, 20 Feb 2008, Christian T. Steigies wrote:
> > IMO aratapif shouldn't be necessary (I use pretty much the same setup with
> > qemu), but aranym calls it anyway and complains if it fails.
>
> Does linux-m68k work with qemu? I read that coldfire is supported by qemu,
> though I did not
On Wed, 20 Feb 2008, Petr Stehlik wrote:
> Geert Uytterhoeven wrote:
> > | Type = bridge
> > | Tunnel = tap0
>
> bridge + tap0 = uml_utilities and no aratapif is necessary.
>
> OTOH
>
> ptp + tun = ipmasq + suid aratapif
>
> And I thought the wiki was almost clear on this subject :-/
Hmm, of c
Petr Stehlik píše v St 20. 02. 2008 v 21:57 +0100:
> Roman Zippel píše v St 20. 02. 2008 v 19:30 +0100:
> > iface tap0 inet static
> > address 192.168.3.133
> > netmask 255.255.255.252
> > tunctl_user roman
> > uml_proxy_arp 192.168.3.134
> > uml_proxy_ether
Roman Zippel píše v St 20. 02. 2008 v 19:30 +0100:
> iface tap0 inet static
> address 192.168.3.133
> netmask 255.255.255.252
> tunctl_user roman
> uml_proxy_arp 192.168.3.134
> uml_proxy_ether eth0
>
> This creates a mini network within the local network. T
On Wed, Feb 20, 2008 at 07:30:07PM +0100, Roman Zippel wrote:
>
> IMO aratapif shouldn't be necessary (I use pretty much the same setup with
> qemu), but aranym calls it anyway and complains if it fails.
Does linux-m68k work with qemu? I read that coldfire is supported by qemu,
though I did not
Hi,
On Wed, 20 Feb 2008, Petr Stehlik wrote:
> Geert Uytterhoeven wrote:
> > | Type = bridge
> > | Tunnel = tap0
>
> bridge + tap0 = uml_utilities and no aratapif is necessary.
Here is my setup, which is specific to Debian: First the uml-utilities
package is needed and then I have this entry i
Geert Uytterhoeven wrote:
| Type = bridge
| Tunnel = tap0
bridge + tap0 = uml_utilities and no aratapif is necessary.
OTOH
ptp + tun = ipmasq + suid aratapif
And I thought the wiki was almost clear on this subject :-/
Petr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "u
On Tue, 19 Feb 2008, Petr Stehlik wrote:
> Geert Uytterhoeven p��e v �t 19. 02. 2008 v 21:40 +0100:
> > On Mon, 18 Feb 2008, Geert Uytterhoeven wrote:
> > > For Atari, the situation is different.
> >
> > I'm still struggling to get networking on Aranym:
> >
> > | TunTap(0): NO_NET_DRIVER_WARN 'ta
Geert Uytterhoeven píše v Út 19. 02. 2008 v 21:40 +0100:
> On Mon, 18 Feb 2008, Geert Uytterhoeven wrote:
> > For Atari, the situation is different.
>
> I'm still struggling to get networking on Aranym:
>
> | TunTap(0): NO_NET_DRIVER_WARN 'tap0': Operation not permitted
> | TunTap(0): NO_NET_DRIV
On Mon, 18 Feb 2008, Geert Uytterhoeven wrote:
> For Atari, the situation is different.
I'm still struggling to get networking on Aranym:
| TunTap(0): NO_NET_DRIVER_WARN 'tap0': Operation not permitted
| TunTap(0): NO_NET_DRIVER_WARN 'tap0': Operation not permitted
While I have:
| [21:38:50]~#
On Tue, 19 Feb 2008, Petr Stehlik wrote:
> Petr Stehlik wrote:
> > Geert Uytterhoeven wrote:
> > > For cfb16 on Falcon I see no direct problems. Perhaps it just failed
> > > because DefaultDepth in /etc/X11/xorg.conf defaults to 24 these days?
> >
> > the problem I faced was that I couldn't *boot*
Petr Stehlik wrote:
Geert Uytterhoeven wrote:
For cfb16 on Falcon I see no direct problems. Perhaps it just failed
because DefaultDepth in /etc/X11/xorg.conf defaults to 24 these days?
the problem I faced was that I couldn't *boot* in the 16bit color depth
so I *thought* I couldn't run X, or
Geert Uytterhoeven wrote:
For cfb16 on Falcon I see no direct problems. Perhaps it just failed
because DefaultDepth in /etc/X11/xorg.conf defaults to 24 these days?
the problem I faced was that I couldn't *boot* in the 16bit color depth
so I *thought* I couldn't run X, or something like that.
30 matches
Mail list logo
