linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] mode change policy

[Petr V. <VAN...@vc...>]

On 14 Jun 01 at 10:46, James Simmons wrote:
> > > They return a error instead. Also what is the policy for cards that can't
> > > change modes. Right now most drivers return a -EINVAL if they can't change
> > > a mode. Do we pass back the only mode the driver supports instead of
> > > returning a error? 
> > 
> > If your vesafb runs in 1280x1024x32, setting 800x600x8 must
> > succeed, but do nothing. 
> 
> So a userland app would assume the video mode is 800x600x8 since it worked
> and was passed back it. Of course the results on the screen would be
> totally wrong. Then how is a userland app to know what the real mode is?

No. fb_set_var must return 1280x1024x32... (argument to fb_set_var
is not const...). Of course I know no app which verifies what
fb_set_var really did - but it is another problem.
                                                Petr
                                                

Re: [Linux-fbdev-devel] Supporting various depth

[James S. <jsi...@tr...>]

> If values required in rgba are not supported by driver, driver should
> do its best to find another possible rgba values.

Agree. 

[Linux-fbdev-devel] Re: mode change policy

[Geert U. <ge...@li...>]

On Thu, 14 Jun 2001, James Simmons wrote:
>    Okay. I realize rounding up is also good for color depth changes.
> Someone could pass in a color depth of 12. We can easily fudge this to
> something that is supported. 
> 
> NOTE: If this is the case then most drivers are broken!!!!

Yep. Few (if any) drivers follow the rules 100%.

> They return a error instead. Also what is the policy for cards that can't
> change modes. Right now most drivers return a -EINVAL if they can't change
> a mode. Do we pass back the only mode the driver supports instead of
> returning a error? 

If you can't change modes, the rule is still to round up, if possible. So if
you try a mode where all parameters <= the only one supported mode, then you
should return the only one supported mode. Else you should return -EINVAL.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] mode change policy

[James S. <jsi...@tr...>]

> > NOTE: If this is the case then most drivers are broken!!!!
> 
> Yes, that is why I asked whether someone knows driver which conforms
> to API...

Off the top of my head vfb.c. I have to go threw the other drivers to see
which one are correct and which are wrong :-(

> > They return a error instead. Also what is the policy for cards that can't
> > change modes. Right now most drivers return a -EINVAL if they can't change
> > a mode. Do we pass back the only mode the driver supports instead of
> > returning a error? 
> 
> If your vesafb runs in 1280x1024x32, setting 800x600x8 must
> succeed, but do nothing. 

So a userland app would assume the video mode is 800x600x8 since it worked
and was passed back it. Of course the results on the screen would be
totally wrong. Then how is a userland app to know what the real mode is?

> I still think that we should
> use highest possible value instead of returning error when we cannot
> round some value up to next possible value. For example vyres comes
> to my (and matroxfb) mind ;-)

I agree. This will especially be true when we support i2c to get monitor
info. Here will will be fudging the hslen etc for the best fit.

Re: [Linux-fbdev-devel] Supporting various depth

[Petr V. <VAN...@vc...>]

On 14 Jun 01 at 18:12, Romain Dolbeau wrote:

> Unfortunately, fbset -depth X should really be fbset -bpp X as it
> means 'set the framebuffer to that number of bits per pixels in
> memory, or more'. For TrueColor mode, there's an option -rgba R,G,B,A
> to give the number of significant bits for each color component. So to
> get Depth 15 in 16 BitsPerPixels, i.e 5 bits for each of red, green
> and blue plus a spare bit, one should use: fbset -depth 16 -rgba
> 5,5,5,1.

For Palletized mode option -rgba reports/selects DAC width - on VGA
either 6 or 8. Not all drivers supports selecting DAC width, but all
must report real width (on normal hardware width of R,G,B should be same,
and width of A should be zero - unless your DAC produces alpha channel).

And I think that we should add into spec:

If values required in rgba are not supported by driver, driver should
do its best to find another possible rgba values.

Reason: In past rgba values were ignored by fb_set_var, and so some
tools (fbset comes to my mind) tries to use '-depth 32 -rgba 5,6,5,0'
when doing 16->32bpp, and other invalid combinations. Requested value
for A channel width must be ignored by driver if requested -depth
cannot have alpha channel on this hardware (and must report A width=0).
                                        
                                        Petr Vandrovec
                                        van...@vc...
                                        

Re: [Linux-fbdev-devel] mode change policy

[Petr V. <VAN...@vc...>]

On 14 Jun 01 at 9:44, James Simmons wrote:

>    Okay. I realize rounding up is also good for color depth changes.
> Someone could pass in a color depth of 12. We can easily fudge this to
> something that is supported. 
> 
> NOTE: If this is the case then most drivers are broken!!!!

Yes, that is why I asked whether someone knows driver which conforms
to API...
 
> They return a error instead. Also what is the policy for cards that can't
> change modes. Right now most drivers return a -EINVAL if they can't change
> a mode. Do we pass back the only mode the driver supports instead of
> returning a error? 

If your vesafb runs in 1280x1024x32, setting 800x600x8 must
succeed, but do nothing. If it runs in 1280x1024x8, and you want
800x600x32, it must return error as 32 > 8! I still think that we should
use highest possible value instead of returning error when we cannot
round some value up to next possible value. For example vyres comes
to my (and matroxfb) mind ;-)
                                        Petr Vandrovec
                                        van...@vc...
                                        

[Linux-fbdev-devel] mode change policy

[James S. <jsi...@tr...>]

   Okay. I realize rounding up is also good for color depth changes.
Someone could pass in a color depth of 12. We can easily fudge this to
something that is supported. 

NOTE: If this is the case then most drivers are broken!!!!

They return a error instead. Also what is the policy for cards that can't
change modes. Right now most drivers return a -EINVAL if they can't change
a mode. Do we pass back the only mode the driver supports instead of
returning a error? 

Re: [Linux-fbdev-devel] 2.4 official API ?

[James S. <jsi...@tr...>]

> I just wanted to know if ther is an official doc/howto about the frame
> buffer API for 2.4 kernel .

It looks like to have to update FB-Driver-HOWTO. 

> is "vfb" up to date, and a good sampleof what should be done ? or is it
> skelettonfb ?

Both should be updated. I can send a patch which also I hope encourages
people to migrate to the new api. I like to thank Russell King for moving
over the arm fbdev drivers to the new api. It makes my life easier :->

Re: [Linux-fbdev-devel] Supporting various depth

[James S. <jsi...@tr...>]

> huh ???
> 
> What special hardware support is needed there. The card is just a multi
> function agp board, with both pm# having their own mmio and fb space, as well
> as the (unused by fbdev) gamma bridge.

This is what I mean. The card has to have two fully functional framebuffers, 
mmio regions and seperate accel engines if used. In a nut shell the hardware
has to have two independent states.

> It is just like a dual card setup. Is there a hardware reason you cannot keep
> vgacon on the first head, and have fbcon setting up a new console on the
> second head ? 

If the card can support being in a vga text state and a graphics state at
the same time then I see no problem. 

> I guess it is more limited by the software, isn't it ? Is it
> possible to have vgacon and fbcon active at the same time with 2.4.+ kernels ?

   Not with 2.4.X :-( The console system uses a gloal struct consw
(conswitchp). You really have to hack up the console system to get it to
work. For me I just rewrote the whole thing. 
   For ruby it is possible but I haven't done it yet. The biggest problem
right now is the current vgacon I have. Lots of global variables. I like
to be able to pass the register region and the text memory region to
vgacon. By default they would be 0x3C0 for the registers and A000 for the
text memory region. Well something like that. These regions are different
on different platforms. Now you could write a small wrapper that passes in
the pci regions. This is what I plan to do for the NVIDIA text mode
driver I have. It pretty much is vgacon except it uses the pci regions
instead. I also plan to vgacon firmware independent as well. 
   As for your case it would be a matter of coordinating both pm3con and
pm3fb together. They have to have the same initialization function to
ensure the correct regions go to the correct console display drivers.  	

> > then. Does the pm2 card have such a feature?
> 
> mmm, don't think so, will have to check it. But the problem is, i think, that
> thec chip don't really knows that something is going wrong.


Some cards can tell if something does go wrong. A example is the ATI
cards. They send out a irq when the accel engine goes bonkers. It is
really for debugging but I can see its use otherwise. Imagine a X server
ontop of ati fbdev and if the X server does something foolish then the
kernel driver would correct itself. This would be a really nice feature.
Plus you get the bonus info in syslog if you use printk to let you know
something went wrong.

Re: [Linux-fbdev-devel] Supporting various depth

[Romain D. <do...@ir...>]

Geert Uytterhoeven wrote:

> No, -depth actually means bits-per-pixel in fbset (yes this is a bug).

Are those details documented anywhere ? That would make life easier
for you not to have to answer questions on fbset all the time :-)

I'm about to add the following blurb to the pm3fb home page to
explain details, so 1) did I understand fbset correctly 2) is
it understandable ? (the pm3fb part is a little optimistic
as the code isn't finished yet ;-)

TIA

####
Depth, BitsPerPixel and fbset

There's a little bit of confusion on the proper use of some terms
in this page and in the fbset software. 

 + Depth should be the actual number of bits used
   for the color of the pixel (above, significants bits) 
 + BitsPerPixel should be the actual number of bits used
   in the memory of the framebuffer per pixel, regardless of depth. 

Unfortunately, fbset -depth X should really be fbset -bpp X as it
means 'set the framebuffer to that number of bits per pixels in
memory, or more'. For TrueColor mode, there's an option -rgba R,G,B,A
to give the number of significant bits for each color component. So to
get Depth 15 in 16 BitsPerPixels, i.e 5 bits for each of red, green
and blue plus a spare bit, one should use: fbset -depth 16 -rgba
5,5,5,1.

At the moment, if you use fbset -depth 15, pm3fb will also use RGB 5551
and 16bpp but I'm not sure it's the right behavior. fbset -depth 16 will
default to RGB 565.
#####


-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

[Linux-fbdev-devel] 2.4 official API ?

[Ghozlane T. <gt...@pr...>]

Hi *

I just wanted to know if ther is an official doc/howto about the frame
buffer API for 2.4 kernel .

is "vfb" up to date, and a good sampleof what should be done ? or is it
skelettonfb ?

thanks in advance .

ghoz

Re: [Linux-fbdev-devel] Supporting various depth

[Sven L. <lu...@dp...>]

On Wed, Jun 13, 2001 at 09:35:40AM -0700, James Simmons wrote:
> > or when loading it ?
> 
> Good point. loading it should reset the mode since you have to set up the
> card anyways with insmoding the driver.
> 
> > Would it be possible to run the vga text console on one head, and a pm3fb on
> > the other ? (same chip).
> 
> The hardware would have to support that. 

huh ???

What special hardware support is needed there. The card is just a multi
function agp board, with both pm# having their own mmio and fb space, as well
as the (unused by fbdev) gamma bridge.

It is just like a dual card setup. Is there a hardware reason you cannot keep
vgacon on the first head, and have fbcon setting up a new console on the
second head ? I guess it is more limited by the software, isn't it ? Is it
possible to have vgacon and fbcon active at the same time with 2.4.+ kernels ?

> > Well, the real problem here is not so much to reset to default mode, but to do
> > a hardware reset on the chip, and initialize it again, to see if the problem
> > goes away.
> 
> This is a problem for hardware that doesn't detect hardware faults. Some
> cards are smart enough to raise a interrupt when the accel engine goes
> bonkers. In the interrupt handler you reset the hardware to a sane state
> then. Does the pm2 card have such a feature?

mmm, don't think so, will have to check it. But the problem is, i think, that
thec chip don't really knows that something is going wrong.

Friendly,

Sven Luther
> 

Re: [Linux-fbdev-devel] ATI rage All in wonder support?

[James S. <jsi...@tr...>]

> > I tried aty128fb and it didn't detect this card. I was wondering if we
> > have patches to support this card. Thanks.
> 
> That is a mach64 based card.

They now make a rage 128 version of this card. We added the below line and
the card now works :-)


/* supported Rage128 chipsets */
static const struct aty128_chip_info aty128_pci_probe_list[] __initdata =
{
    {"Rage128 PD (PCI)", PCI_DEVICE_ID_ATI_Rage128_PD, rage_128_pro},

[Linux-fbdev-devel] Re: sis630 - help needed debugging in the kernel

[René R. <ren...@gm...>]

Thanks for the quick reply!

On Wed, 13 Jun 2001 09:54:21 -0700 (PDT)
James Simmons <jsi...@tr...> wrote:

> 
> > I currently try to debug why the sisfb driver crashes my machine. (SIS 630
> > based laptop - linux-2.4.5-ac13).
> 
> You can do one of two things. Post both System.map and the complete oops
> or you can run ksymoops on the oops. I can find the problem then. Thanks.

ksymoops' output is attached.

[...]

k33p h4ck1n6 René

-- 
René Rebe (Registered Linux user: #127875)
http://www.rene.rebe.myokay.net/
-Germany-

Anyone sending unwanted advertising e-mail to this address will be charged
$25 for network traffic and computing time. By extracting my address from
this message or its header, you agree to these terms.

Re: [Linux-fbdev-devel] ATI rage All in wonder support?

[Brad D. <br...@ne...>]

On 13 Jun 2001 11:28:01 -0700, James Simmons wrote:
> 
> I tried aty128fb and it didn't detect this card. I was wondering if we
> have patches to support this card. Thanks.

That is a mach64 based card.

Brad Douglas
br...@ne...

[Linux-fbdev-devel] ATI rage All in wonder support?

[James S. <jsi...@tr...>]

I tried aty128fb and it didn't detect this card. I was wondering if we
have patches to support this card. Thanks.

Re: [Linux-fbdev-devel] Supporting various depth

[James S. <jsi...@tr...>]

> > If we go by -depth really means -bpp then make it fail. If the user uses
> 
> Wrong. The rules are to round a value up if it doesn't fit and if possible.

So the basic approach is avoid failure at all cost :-) 

Re: [Linux-fbdev-devel] Supporting various depth

[Geert U. <ge...@li...>]

On Wed, 13 Jun 2001, James Simmons wrote:
> > So what should happen if you try to set depth 24 with fbset ? Silently set 32
> > bpp ? reject it ?
> >
> > Same goes for depth 15 ? should it silently be set to bpp 16, RGBA 5551, or
> > rejected ?
> 
> If we go by -depth really means -bpp then make it fail. If the user uses

Wrong. The rules are to round a value up if it doesn't fit and if possible.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] Re: sis630 - help needed debugging in the kernel

[James S. <jsi...@tr...>]

> I currently try to debug why the sisfb driver crashes my machine. (SIS 63=
0
> based laptop - linux-2.4.5-ac13).

You can do one of two things. Post both System.map and the complete oops
or you can run ksymoops on the oops. I can find the problem then. Thanks.

> On my serial-console I get:
> [...]
> sisfb: framebuffer at 0xe0000000, mapped to 0xcb800000, size 16384k
> sisfb: MMIO at 0xefce0000, mapped to 0xcc801000, size 128k
> sisfb: encountered LCD # debug output by me
> sisfb: fall back to 1024x768 # debug ouput by me
> sisfb: LCD mode # debug output by me
> sisfb: mode is 800x600x8, linelength=3D800
> [...]
> Unable to handle kernel paging request at virtual address cc800180
> [oops]
>=20
> This happens in the method: register_framebuffer called from sisfb_init.
>=20
> I compared the sisfb_init with other framebuffer drivers and can't find w=
hat is wrong.
> (I normally don't do kernel hacking...). What does the kernel try to do w=
ith the
> _io-memory_, mapped around line 2230 in sis_main.c? - Must the memory req=
euested or
> mapped in an other way?
>=20
> Another strange thing is, that the code seems to work for some people ...
>=20
> I would be nice if anyone could give me a hint - because the sis-drivers =
(kernel and X)
> doesn't work for many people ...
>=20
> k33p h4ck1n6 Ren=E9
>=20
> --=20
> Ren=E9 Rebe (Registered Linux user: #127875)
> http://www.rene.rebe.myokay.net/
> -Germany-
>=20
> Anyone sending unwanted advertising e-mail to this address will be charge=
d
> $25 for network traffic and computing time. By extracting my address from
> this message or its header, you agree to these terms.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to maj...@vg...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>=20

Re: [Linux-fbdev-devel] Supporting various depth

[James S. <jsi...@tr...>]

> > Ok, what about the fbdev driver silently converting bpp 15 to bpp 16 and
> > setting RGB5551 ?
> 
> Why? API is complicated enough just now (btw, does anybody know driver
> which implements this API correctly? I do not...)

Such a mess. As in my other post we are going to get into a whole heap of
trouble when we start supporting cards with multiple buffers of many
different types. We even run into this problem now. Some cards have
seperate buffer for YUV. What do we use for rgba values then? Of course
this will require heavy thinking on how to clear this up. 
    Anyways I will be working on a fbdev filesystem as discussed on the
lkml in the near future. I haven't found time yet but I will get to it.
This will give us the chance to start with a new better userland api. Plus
using a filesystem gives us other advantages. 

Re: [Linux-fbdev-devel] Supporting various depth

[James S. <jsi...@tr...>]

> Sorry, my twisted mind read memcpy() instead of memcmp().

No problem. Been their, done that.

Re: [Linux-fbdev-devel] Supporting various depth

[James S. <jsi...@tr...>]

> mmm, well, the problem is that most current 'millions of color' modes are in
> truth depth 24 ones, which are internally either 32bpp (as in the permedia3
> case) or 24bpp (saves bandwith, but no alpha channel and you may be forced to
> do some shifting).

Ugh!!!! This is a bug in fbset. It shouldn't be called depth. It should be
bpp. Depth is how the number of bits used to represent a color in a pixel.
bpp is how many bits per pixel. A good example would be a card with a 80
bpp. Out of the 80 bpp only 30 are used for rbg space (10:10:10). The rest
could be window IDs, depth buffer values etc. fbset should be using -bpp
and you use -rgba to set the size of each field. Unfortunely the current
fbdev api doesn't support things beyond RGBA in the buffer :-( 

> So what should happen if you try to set depth 24 with fbset ? Silently set 32
> bpp ? reject it ?
>
> Same goes for depth 15 ? should it silently be set to bpp 16, RGBA 5551, or
> rejected ?

If we go by -depth really means -bpp then make it fail. If the user uses
-rgba along with it then make it work. Some cards have the alpha channel
as a seperate buffer. So these cards really have 24 bpp modes (8:8:8)
where you have to use a seperate buffer to access the alpha channels. The
same goes with cards with window IDs. Some have windows IDs interwoven
with the framebuffer. Other do not. Here we don't even have a alpha
channel. We still have 32 bpp but the depth is 24. The other 8 bits being
a window ID value. 

BTW we could treat the alpha channel as another framebuffer with
(0:0:0:8). Here with have a depth of 0 and bpp of 8. Right? Other types of
buffers could be treated the same way as well. Again fbdev doesn't support
this at present tho :-( That will have to change but this breaks backwards
compatibility.

> > > Also, i am experiencing some (maybe hardware) bugs, and would like to reset
> > > the graphic chip. Is there an existing way to do this kind of stuff via ioctl
> > > ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev
> > > would be really happy with it).
> > 
> >    Not really. You could make it reset the card when unloading the module.
> 
> or when loading it ?

Good point. loading it should reset the mode since you have to set up the
card anyways with insmoding the driver.

> Would it be possible to run the vga text console on one head, and a pm3fb on
> the other ? (same chip).

The hardware would have to support that. 

> Well, the real problem here is not so much to reset to default mode, but to do
> a hardware reset on the chip, and initialize it again, to see if the problem
> goes away.

This is a problem for hardware that doesn't detect hardware faults. Some
cards are smart enough to raise a interrupt when the accel engine goes
bonkers. In the interrupt handler you reset the hardware to a sane state
then. Does the pm2 card have such a feature?

Re: [Linux-fbdev-devel] Supporting various depth

[Petr V. <VAN...@vc...>]

On 13 Jun 01 at 18:12, Sven LUTHER wrote:
> On Wed, Jun 13, 2001 at 05:29:44PM +0200, Geert Uytterhoeven wrote:
> > On Wed, 13 Jun 2001, Sven LUTHER wrote:
> > > On Wed, Jun 13, 2001 at 03:49:41PM +0200, Geert Uytterhoeven wrote:
> > 
> > No, -depth actually means bits-per-pixel in fbset (yes this is a bug).
> 
> Ok, what about the fbdev driver silently converting bpp 15 to bpp 16 and
> setting RGB5551 ?

Why? API is complicated enough just now (btw, does anybody know driver
which implements this API correctly? I do not...)
                                                Best regards,
                                                    Petr Vandrovec
                                                    van...@vc...

Re: [Linux-fbdev-devel] Supporting various depth

[Geert U. <ge...@li...>]

On Wed, 13 Jun 2001, Sven LUTHER wrote:
> On Wed, Jun 13, 2001 at 05:29:44PM +0200, Geert Uytterhoeven wrote:
> > On Wed, 13 Jun 2001, Sven LUTHER wrote:
> > > On Wed, Jun 13, 2001 at 03:49:41PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> > > > > Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
> > > > > the fbdev/fbcon layer ?
> > > > 
> > > > Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
> > > > 
> > > > > pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
> > > > > (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
> > > > > and support both internally, is there a requirement that
> > > > > CFB16 is one or the other, ... ?
> > > > 
> > > > Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> > > > like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
> > > 
> > > So i suppose saying fbset -depth 15 could be done to switch the fb to
> > > RGBA5551 mode ? 
> > 
> > No, -depth actually means bits-per-pixel in fbset (yes this is a bug).
> 
> Ok, what about the fbdev driver silently converting bpp 15 to bpp 16 and
> setting RGB5551 ?

Yes, that's allowed.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] Supporting various depth

[Geert U. <ge...@li...>]

On Wed, 13 Jun 2001, James Simmons wrote:
> > > int fb_set_var(struct fb_var_screeninfo *var, struct fb_info *info)
> > > {
> > >     int oldbpp, err;
> > > 
> > >     if (memcmp(&info->var, var, sizeof(var))) {
> > >         if ((err = info->fbops->fb_check_var(var, info)))
> > >                 return err;
> > 
> > This is not correct, since it first overwrites the old var, then checks whether
> > the new one is valid. If that test fails, you're left with an invalid var in
> > info->var.
> 
> That is a memory compare. It checks to see if the purposed mode is the
> same as the current mode. If not then fb_check_var is called to test the
> new var. info->var = var only if var->activate == FB_ACTIVATE_NOW and
> their is a set_par function. You can set info->var = *var before set_par
> is called because we trust check_var did its job. 

Sorry, my twisted mind read memcpy() instead of memcmp().

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds