Re: alt->meta->esc status quo

2001-12-16 Thread Tor Slettnes

> "Charl" == Charl P Botha <[EMAIL PROTECTED]> writes:

Charl> Dear Debian-Xers, At the moment, I need to set the X
Charl> resource xterm*metaSendsEscape to true and to do xmodmap -e
Charl> "keysym Alt_L = Meta_L Alt_L" to get Alt+key combinations
Charl> to work in an xterm, e.g. on the command-line (e.g. alt-f
Charl> and alt-b for skipping words forwards and backwards) or in
Charl> programs like JED.

Charl> Am I doing something wrong, or is this how it's supposed to
Charl> be?  I've checked the xterm FAQ as well as the
Charl> xserver-common FAQ and some of the old BTS reports, but
Charl> couldn't find closure on this matter.  Any clarification
Charl> would be most welcome, as this matter comes up every so
Charl> often.


Use the resources 'XTerm*modifier: meta', or 'XTerm*modifier: alt', as
you see fit.

-tor

-- 
Får i ulveklær



Re: alt->meta->esc status quo

2001-12-15 Thread Tor Slettnes


> "Charl" == Charl P Botha <[EMAIL PROTECTED]> writes:

Charl> Dear Debian-Xers, At the moment, I need to set the X
Charl> resource xterm*metaSendsEscape to true and to do xmodmap -e
Charl> "keysym Alt_L = Meta_L Alt_L" to get Alt+key combinations
Charl> to work in an xterm, e.g. on the command-line (e.g. alt-f
Charl> and alt-b for skipping words forwards and backwards) or in
Charl> programs like JED.

Charl> Am I doing something wrong, or is this how it's supposed to
Charl> be?  I've checked the xterm FAQ as well as the
Charl> xserver-common FAQ and some of the old BTS reports, but
Charl> couldn't find closure on this matter.  Any clarification
Charl> would be most welcome, as this matter comes up every so
Charl> often.


Use the resources 'XTerm*modifier: meta', or 'XTerm*modifier: alt', as
you see fit.

-tor

-- 
Får i ulveklær


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: XFree86 4.0.2 status

2001-01-08 Thread Tor Slettnes

> "Michel" == Michel Dänzer <[EMAIL PROTECTED]> writes:

Michel> There is a SYMFUNC for memcpy which is guarded by

Michel> #if (defined(__powerpc__) && (defined(Lynx) || defined(linux))) || 
defined(__sparc__) || defined(__ia64__) 

Michel> /* * Some PPC, SPARC, and IA64 compilers generate calls to
Michel> memcpy to handle * structure copies.  This causes a
Michel> problem both here and in shared * libraries as there is no
Michel> way to map the name of the call to the * correct function.
Michel> */

Yep, I noticed that one.  In fact, I'm trying again now with just that
one line modified.

Thanks!

-tor

-- 
Får i ulveklær



Re: XFree86 4.0.2 status

2001-01-08 Thread Tor Slettnes


> "Michel" == Michel Dänzer <[EMAIL PROTECTED]> writes:

Michel> There is a SYMFUNC for memcpy which is guarded by

Michel> #if (defined(__powerpc__) && (defined(Lynx) || defined(linux))) || 
defined(__sparc__) || defined(__ia64__) 

Michel> /* * Some PPC, SPARC, and IA64 compilers generate calls to
Michel> memcpy to handle * structure copies.  This causes a
Michel> problem both here and in shared * libraries as there is no
Michel> way to map the name of the call to the * correct function.
Michel> */

Yep, I noticed that one.  In fact, I'm trying again now with just that
one line modified.

Thanks!

-tor

-- 
Får i ulveklær


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: XFree86 4.0.2 status

2001-01-08 Thread Tor Slettnes
> "Christian" == Christian T Steigies <[EMAIL PROTECTED]> writes:

Christian> Tell me... and _that_ part _was_ working in a previous
Christian> build. And I did not change much on my build system
Christian> since then, I only installed (and built) glibc2.2 and
Christian> gcc-2.95.3 ;-)

I got the same run-time errors on ARM, built with the same gcc/glibc.

Phil Blundell suggested looking in
xc/programs/Xserver/hw/xfree86/loader/xf86sym.c, and create
appropriate system-dependent SYMVARS.  I am about to look into that
now. 

-tor


-- 
Får i ulveklær



Re: XFree86 4.0.2 status

2001-01-08 Thread Tor Slettnes

> "Christian" == Christian T Steigies <[EMAIL PROTECTED]> writes:

Christian> Tell me... and _that_ part _was_ working in a previous
Christian> build. And I did not change much on my build system
Christian> since then, I only installed (and built) glibc2.2 and
Christian> gcc-2.95.3 ;-)

I got the same run-time errors on ARM, built with the same gcc/glibc.

Phil Blundell suggested looking in
xc/programs/Xserver/hw/xfree86/loader/xf86sym.c, and create
appropriate system-dependent SYMVARS.  I am about to look into that
now. 

-tor


-- 
Får i ulveklær


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: XFree86 4.0.2 status

2001-01-07 Thread Tor Slettnes
> "Branden" == Branden Robinson <[EMAIL PROTECTED]> writes:

Branden> If you absolutely have to make changes to the 4.0.2-1
Branden> sources, please do them by stealth 

Ok.  Unfortunately the patches I sent you earlier don't build an X
server for ARM, so I will do what you just said.  (I.e. send you
updated patches, once it is built cleanly, and upload binary-only as
4.0.2-1).

-tor



Re: XFree86 4.0.2 status

2001-01-06 Thread Tor Slettnes

> "Branden" == Branden Robinson <[EMAIL PROTECTED]> writes:

Branden> If you absolutely have to make changes to the 4.0.2-1
Branden> sources, please do them by stealth 

Ok.  Unfortunately the patches I sent you earlier don't build an X
server for ARM, so I will do what you just said.  (I.e. send you
updated patches, once it is built cleanly, and upload binary-only as
4.0.2-1).

-tor


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: XFree86 4.0.2 status

2001-01-06 Thread Tor Slettnes
> "Philip" == Philip Blundell <[EMAIL PROTECTED]> writes:

Philip> I'd suggest you go ahead and upload the client and library
Philip> packages, even if you can't make the server work.  That
Philip> way at least the autobuilder can start to clear the
Philip> backlog of packages that are stuck waiting for xlibs-dev
Philip> to become available.

Good enough, I will make a NMU upload tomorrow.  (I just started
another build, before seeing this message).

-tor

-- 
Får i ulveklær



Re: XFree86 4.0.2 status

2001-01-06 Thread Tor Slettnes

> "Philip" == Philip Blundell <[EMAIL PROTECTED]> writes:

Philip> I'd suggest you go ahead and upload the client and library
Philip> packages, even if you can't make the server work.  That
Philip> way at least the autobuilder can start to clear the
Philip> backlog of packages that are stuck waiting for xlibs-dev
Philip> to become available.

Good enough, I will make a NMU upload tomorrow.  (I just started
another build, before seeing this message).

-tor

-- 
Får i ulveklær


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: XFree86 4.0.2 status

2001-01-06 Thread Tor Slettnes
> "Chris" == Chris Rutter <[EMAIL PROTECTED]> writes:

Chris> I've heard now that a variety of different people are
Chris> working on XF4 for arm -- could the people who actually
Chris> are/ possibly stick their hand up; I'm willing to patch up
Chris> anything that I can, but I don't wish to tread on anyone's
Chris> toes...

*one hand, hesitantly*

I don't think you need to worry about the stepping part.  The sooner
any of us can show anything, the better. :-/

I've given it two more shots the last two days (it takes about 12
hours to build), after getting a working gcc/g++ and glibc22 in order.

Each time I did something stupid (had uninstalled zlib-dev, and
forgotten to reapply a couple of patches I hadn't given Branden yet,
after getting new source).

I'm doing another build right now. :^}

-tor



Re: XFree86 4.0.2 status

2001-01-06 Thread Tor Slettnes

> "Chris" == Chris Rutter <[EMAIL PROTECTED]> writes:

Chris> I've heard now that a variety of different people are
Chris> working on XF4 for arm -- could the people who actually
Chris> are/ possibly stick their hand up; I'm willing to patch up
Chris> anything that I can, but I don't wish to tread on anyone's
Chris> toes...

*one hand, hesitantly*

I don't think you need to worry about the stepping part.  The sooner
any of us can show anything, the better. :-/

I've given it two more shots the last two days (it takes about 12
hours to build), after getting a working gcc/g++ and glibc22 in order.

Each time I did something stupid (had uninstalled zlib-dev, and
forgotten to reapply a couple of patches I hadn't given Branden yet,
after getting new source).

I'm doing another build right now. :^}

-tor


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: building xfree86 4 for debian/arm

2000-12-11 Thread Tor Slettnes
> "Peter" == Peter Maydell <[EMAIL PROTECTED]> writes:

Peter> I tried putting together some patches based on a
Peter> combination of the 3.x ARM patches and the 4.0 patches for
Peter> other non-x86 architectures; it's now falling over with a
Peter> compile error in elfloader.c. It looks like the dynamic
Peter> loader has no ARM support at all, and I don't think I can
Peter> get away with just adding "|| defined(__arm__)" to cpp
Peter> conditionals for this one :->

I have been playing with this for the last couple of weeks.
After getting elfloader.c to compile with the most common relocation
types (R_ARM_ABS32, R_ARM_REL32, R_ARM_PC24) defined, there are still
a couple outstanding:

(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
Elf_RelocateEntry() Unsupported relocation type 56
Elf_RelocateEntry() Unsupported relocation type 24


24 happens to be:

#define R_ARM_GOTOFF24  /* 32 bit offset to GOT */

By itself this is pretty odd, but #56 is simply not defined in
/usr/include/elf.h at all.  I am rebuilding right now (a 10-hour
process) with "Elf_Rel" rather than "Elf_Rela" setup, to see if that
makes a difference.  (Seing that ARM, like i386, unlike any of the
other processors, is Little Endian).



Peter> I've temporarily put my patches-so-far at:
Peter> http://www.chiark.greenend.org.uk/~pmaydell/misc/patches.txt
Peter> if anybody else is interested.  (NB that in particular the
Peter> list of 'which drivers to build' in xfree86.cf is totally
Peter> guesswork...)

Framebuffer stuff.   I have changed the section that starts with:

#if defined(PpcArchitecture) || defined(Mc68020Architecture)

to

#if defined(PpcArchitecture) || defined(Mc68020Architecture) || \
defined(Arm32Architecture)


-tor



-- 
Får i ulveklær



Re: building xfree86 4 for debian/arm

2000-12-11 Thread Tor Slettnes

> "Peter" == Peter Maydell <[EMAIL PROTECTED]> writes:

Peter> I tried putting together some patches based on a
Peter> combination of the 3.x ARM patches and the 4.0 patches for
Peter> other non-x86 architectures; it's now falling over with a
Peter> compile error in elfloader.c. It looks like the dynamic
Peter> loader has no ARM support at all, and I don't think I can
Peter> get away with just adding "|| defined(__arm__)" to cpp
Peter> conditionals for this one :->

I have been playing with this for the last couple of weeks.
After getting elfloader.c to compile with the most common relocation
types (R_ARM_ABS32, R_ARM_REL32, R_ARM_PC24) defined, there are still
a couple outstanding:

(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
Elf_RelocateEntry() Unsupported relocation type 56
Elf_RelocateEntry() Unsupported relocation type 24


24 happens to be:

#define R_ARM_GOTOFF24  /* 32 bit offset to GOT */

By itself this is pretty odd, but #56 is simply not defined in
/usr/include/elf.h at all.  I am rebuilding right now (a 10-hour
process) with "Elf_Rel" rather than "Elf_Rela" setup, to see if that
makes a difference.  (Seing that ARM, like i386, unlike any of the
other processors, is Little Endian).



Peter> I've temporarily put my patches-so-far at:
Peter> http://www.chiark.greenend.org.uk/~pmaydell/misc/patches.txt
Peter> if anybody else is interested.  (NB that in particular the
Peter> list of 'which drivers to build' in xfree86.cf is totally
Peter> guesswork...)

Framebuffer stuff.   I have changed the section that starts with:

#if defined(PpcArchitecture) || defined(Mc68020Architecture)

to

#if defined(PpcArchitecture) || defined(Mc68020Architecture) || \
defined(Arm32Architecture)


-tor



-- 
Får i ulveklær


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: XFree86 4.0.1 architecture status

2000-11-27 Thread Tor Slettnes

I shall give it a try.

Give you a hollar tomorrow w/status.

-tor

> "Branden" == Branden Robinson <[EMAIL PROTECTED]> writes:

Branden> arm: I haven't heard a peep out of anyone about XF4 on
Branden> the ARM.  Would someone please contact me about this?



Re: XFree86 4.0.1 architecture status

2000-11-27 Thread Tor Slettnes


I shall give it a try.

Give you a hollar tomorrow w/status.

-tor

> "Branden" == Branden Robinson <[EMAIL PROTECTED]> writes:

Branden> arm: I haven't heard a peep out of anyone about XF4 on
Branden> the ARM.  Would someone please contact me about this?


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]