Re: Changes in Kernel

Re: Changes in Kernel

[Alan Cox]

>   We are interested in making some changes to the linux kernel so that it
> supports some indian type fonts on the console... so what are the special
> things that we sould take care of so that our work would be included in
> the kernel-distribution, and how do we proceed about getting it included
> in the distributions?

Are there specific reasons you cannot just use the existing ioctls to load
fonts ? The console driver already supports Klingon for example.

What are the issues - writing right - left ?

Alan

Re: Changes in Kernel

[H. Peter Anvin]

Followup to:  <E152GlV-0002Hh-00@the-village.bc.nu>
By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
>
> >   We are interested in making some changes to the linux kernel so that it
> > supports some indian type fonts on the console... so what are the special
> > things that we sould take care of so that our work would be included in
> > the kernel-distribution, and how do we proceed about getting it included
> > in the distributions?
> 
> Are there specific reasons you cannot just use the existing ioctls to load
> fonts ? The console driver already supports Klingon for example.
> 
> What are the issues - writing right - left ?
> 

Indian languages have complicated character/glyph mappings, similar to
Arabic but worse.

In general, these kinds of things is much better handled in user
space, similar to the way Asian languages are handled using the user
space console program "kon".  You would typically use the frame buffer
driver in the kernel and maintain the complicated state machines and
glyph sets in user space.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Changes in Kernel

[Prasad]

  We are interested in making some changes to the linux kernel so that it
supports some indian type fonts on the console... so what are the special
things that we sould take care of so that our work would be included in
the kernel-distribution, and how do we proceed about getting it included
in the distributions?

Thanx in Advance
Prasad <prasad_s@gdit.iiit.net>

Re: Changes in Kernel

[Vivek Dasmohapatra]

On Tue, 22 May 2001, Alan Cox wrote:

> Are there specific reasons you cannot just use the existing ioctls to load
> fonts ? The console driver already supports Klingon for example.
> 
> What are the issues - writing right - left ?

No, but in some scripts [devanagari anyway] you only ever write a vowel as
a letter if it's at the front of the word: otherwise vowels are added as 
sort of 'accents' to the consonants, plus there are letters that sometimes
smoosh together if they are next to one another, iirc, and long and short
forms for each vowel, and each accent-form, plus there are other
idiosyncrasies...

There seems to be kanji console thing called kon, looking at the package,
it looks like it's implemented in userspace - perhaps a similar approach
would be fruitful?

-- 
Just one nuclear family can ruin your whole life.

Xircom RealPort versus 3COM 3C3FEM656C

[Dax Kelson]

I currently have three Xircom RealPort Carbus modem/fast ethernet cards.
The current driver blows major chunks (it has very poor performance, and
stops working under load).  I'm told the driver issues are because of
hardware issues. The really nice feature of this card is the form factor
though.

3COM has a new card that has a form factor like the Xircom RealPort.  It
is the 3C3FEM656C card.  You and find information about it here:

http://www.3com.com/products/en_US/detail.jsp?pathtype=purchase&tab=features&sku=3C3FEM656C

I've been unable to find information about Linux support for this 3COM
card.

Is the modem a win modem, or a regular modem?  Is there any planned
support for this 3COM card?

Dax

Re: Xircom RealPort versus 3COM 3C3FEM656C

[Alan Cox]

> I currently have three Xircom RealPort Carbus modem/fast ethernet cards.
> The current driver blows major chunks (it has very poor performance, and
> stops working under load).  I'm told the driver issues are because of
> hardware issues. The really nice feature of this card is the form factor
> though.

Before you give up on the xircom thing, try the -ac kernel and set the box
up to use xircom_cb not xircom_tulip_cb

That might help a lot

Re: Xircom RealPort versus 3COM 3C3FEM656C

[Jeff Garzik]

On Tue, 22 May 2001, Alan Cox wrote:

> > I currently have three Xircom RealPort Carbus modem/fast ethernet cards.
> > The current driver blows major chunks (it has very poor performance, and
> > stops working under load).  I'm told the driver issues are because of
> > hardware issues. The really nice feature of this card is the form factor
> > though.
> 
> Before you give up on the xircom thing, try the -ac kernel and set the box
> up to use xircom_cb not xircom_tulip_cb
> 
> That might help a lot

Note that the reason why xircom_cb for all cases is that it sets the
card into promisc mode, in all cases.  This punishes your CPU and laptop
battery on a loaded network.

Promisc mode is required because (AFAIK) Xircoms under the same PCI id
can use any one of three setup frame formats, and only one format is
known.

So, you are right, xircom_cb will help a lot in most cases, but the
hardware sucks.  I recommend avoiding it...

	Jeff


P.S. If anybody knows Xircom engineers, we would love a tech contact...

Re: Xircom RealPort versus 3COM 3C3FEM656C

[Ion Badulescu]

On Tue, 22 May 2001 20:10:41 +0100 (BST), Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Before you give up on the xircom thing, try the -ac kernel and set the box
> up to use xircom_cb not xircom_tulip_cb
> 
> That might help a lot

It doesn't, it still performs poorly with any of the three available
drivers -- xircom_cb, xircom_tulip_cb, and tulip_cb (from the pcmcia package):

* Rx gets only about 1.8Mbit/s on a 100Base-TX network with any of the three
* Tx gets 80+Mb/s with xircom_tulip_cb and tulip_cb, and less than 30Mb/s
  with xircom_cb.

And no, promisc mode played no role in this experiment, because my test
network is switched and otherwise very quiet.

Windows drivers handle both Rx and Tx at full speed.

I have this feeling that we're handling the card in some (tulip) compat
mode, which severely cripples performance. It's hard to tell, without
docs...

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

Re: Xircom RealPort versus 3COM 3C3FEM656C

[arjan]

In article <200105222118.f4MLISL01588@moisil.badula.org> you wrote:
> On Tue, 22 May 2001 20:10:41 +0100 (BST), Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

>> Before you give up on the xircom thing, try the -ac kernel and set the box
>> up to use xircom_cb not xircom_tulip_cb
>> 
>> That might help a lot

> It doesn't, it still performs poorly with any of the three available
> drivers -- xircom_cb, xircom_tulip_cb, and tulip_cb (from the pcmcia package):

> * Rx gets only about 1.8Mbit/s on a 100Base-TX network with any of the three
> * Tx gets 80+Mb/s with xircom_tulip_cb and tulip_cb, and less than 30Mb/s
>  with xircom_cb.

This sounds like a bug I have heard before: some switches don't work with
the xircom card (well, our drivers for it) when doing full duplex.
Could you try the latest driver from 

http://people.redhat.com/arjanv

which forces the card to half-duplex? 
I manage to get 8Mbyte/sec with it without any problems.

Greetings,
   Arjan van de Ven

Re: Xircom RealPort versus 3COM 3C3FEM656C

[Ion Badulescu]

On Tue, 22 May 2001 arjan@fenrus.demon.nl wrote:

> This sounds like a bug I have heard before: some switches don't work with
> the xircom card (well, our drivers for it) when doing full duplex.
> Could you try the latest driver from 
> 
> http://people.redhat.com/arjanv
> 
> which forces the card to half-duplex? 

I doesn't help, the switch still thinks it's running in full-duplex mode.
Performance is obviously the same.

The switch I have is not managed, so there is nothing I can do on that 
front. Any other suggestions?

[BTW, you've removed too many includes, the driver doesn't compile anymore 
in the 2.4.4-ac tree.]

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.