Thread (5 messages) 5 messages, 2 authors, 2004-07-14

Re: HP300 support checked in

flat view

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2004-07-13 08:08:28

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 13:03:41 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--

--i6CB3kXJ003893.1089630226/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 16:24:28 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 13:03:41 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--

--i6CB3kXJ003893.1089630226/witte.sonytel.be--

--i6CEOWXJ026457.1089642272/witte.sonytel.be--
ReSent-Date: Tue, 13 Jul 2004 10:08:20 +0200 (MEST)
ReSent-From: Geert Uytterhoeven [off-list ref]
ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
ReSent-Subject: Re: HP300 support checked in
ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 13:03:41 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--

--i6CB3kXJ003893.1089630226/witte.sonytel.be--
ReSent-Date: Mon, 12 Jul 2004 16:24:28 +0200 (MEST)
ReSent-From: Geert Uytterhoeven [off-list ref]
ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
ReSent-Subject: Re: HP300 support checked in
ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
X-ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
X-ReSent-From: Geert Uytterhoeven [off-list ref]
X-ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
X-ReSent-Subject: Re: HP300 support checked in
X-ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--
ReSent-Date: Mon, 12 Jul 2004 13:03:41 +0200 (MEST)
ReSent-From: Geert Uytterhoeven [off-list ref]
ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
ReSent-Subject: Re: HP300 support checked in
ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--
ReSent-Date: Mon, 12 Jul 2004 09:44:53 +0200 (MEST)
ReSent-From: Geert Uytterhoeven [off-list ref]
ReSent-To: 
    Linux Frame Buffer Device Development [off-list ref]
ReSent-Subject: Re: HP300 support checked in
ReSent-Message-ID: [off-list ref]

On Sun, 11 Jul 2004, Kars de Jong wrote:
Support for <8 bit framebuffers is probably broken. I don't know how I'm
going to support them yet. It used to be "special-cased" in
drivers/video/fbcon.c.

They are laid out in memory like normal 8 bit chunky framebuffers, but
the upper bits are basically ignored.

So for blitting purposes the bits_per_pixel == 8 code should be used,
but just setting bits_per_pixel to 8 doesn't work because then the
amount of colours is assumed to be 256.

I think we basically need to distinguish between bpp and depth.
What are the possible values of depth? Just 1 (monochrome)? Or also 4 (16
colors)?

If it's just 1 (monochrome), you can probably get away with setting
var.bits_per_pixel = 256 and fix.visual = FB_VISUAL_MONO01 (or MONO10).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

--i6C7PIXJ008765.1089617118/witte.sonytel.be--

--i6C7ivXJ010717.1089618297/witte.sonytel.be--

--i6CB3kXJ003893.1089630226/witte.sonytel.be--

--i6CEOWXJ026457.1089642272/witte.sonytel.be--


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help