[edk2] ConOut Protocol

Discussion:

Michael Chang

2012-06-01 07:58:14 UTC

Hi,

In UEFI spec, it mentioned about the ConOut global UEFI variable is
the device path (EFI_DEVICE_PATH_PROTOCOL) of default output console,
but seems don't have description on ConOut protocol, which I could only
find on EFI 1.10 Driver Writer's Guide

"Driver #32 will install a ConOut device GUID on the handle if the
device path is listed in the ConOut global EFI variable ..."

"EFI uses these three protocols (ConIn, ConOut, and ErrOut) to mark
devices in the system, which have been selected by the user as ConIn,
ConOut, and StdErr. These protocols are actually just a GUID without
any services or data."

On my UEFI desktop "dh -p ConOut" reveals the handles.

I interested in this topic is becasue I want to leverage this protocol
to judge the correct handle if there are more than one handle provides
GOP protocol. For example, elilo simply picks the first located device
handle with GOP and use it, however in some circumstance it leads to a
garbled screen due to the handle is not associated with the real
physical output device.

But I am now afarid that since this protocol is not in specifcation,
it would not be mandatory for drivers to install it and may need to
figure out other way to circumvant it (or anyone has good suggestion
to judge the correct handle to use for GOP mode information during
boot? )

Thanks,
Michael

Richardson, Brian

2012-06-01 15:20:18 UTC

Permalink

ConOut is the device path of the console output device.

The related protocol is EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL, which is described in the UEFI specification.

There is information related to ConOut in the updated Driver Writer's Guide for UEFI 2.3.1 ...
http://sourceforge.net/projects/edk2/files/EDK%20II%20Releases/Driver_Developer/

Thanks ... br
---
Brian Richardson -- ***@intel.com -- Twitter: intel_brian

-----Original Message-----
From: Michael Chang [mailto:***@suse.com]
Sent: Friday, June 01, 2012 3:58 AM
To: edk2-***@lists.sourceforge.net
Subject: [edk2] ConOut Protocol

Hi,

In UEFI spec, it mentioned about the ConOut global UEFI variable is the device path (EFI_DEVICE_PATH_PROTOCOL) of default output console, but seems don't have description on ConOut protocol, which I could only find on EFI 1.10 Driver Writer's Guide

"Driver #32 will install a ConOut device GUID on the handle if the device path is listed in the ConOut global EFI variable ..."

"EFI uses these three protocols (ConIn, ConOut, and ErrOut) to mark devices in the system, which have been selected by the user as ConIn, ConOut, and StdErr. These protocols are actually just a GUID without any services or data."

On my UEFI desktop "dh -p ConOut" reveals the handles.

I interested in this topic is becasue I want to leverage this protocol to judge the correct handle if there are more than one handle provides GOP protocol. For example, elilo simply picks the first located device handle with GOP and use it, however in some circumstance it leads to a garbled screen due to the handle is not associated with the real physical output device.

But I am now afarid that since this protocol is not in specifcation, it would not be mandatory for drivers to install it and may need to figure out other way to circumvant it (or anyone has good suggestion to judge the correct handle to use for GOP mode information during boot? )

Thanks,
Michael

Andrew Fish

2012-06-01 16:23:17 UTC

Permalink

Post by Michael Chang
Hi,
In UEFI spec, it mentioned about the ConOut global UEFI variable is
the device path (EFI_DEVICE_PATH_PROTOCOL) of default output console,
but seems don't have description on ConOut protocol, which I could only
find on EFI 1.10 Driver Writer's Guide

These protocols are part part of an implementation of the platforms console splitter and not part of the specification.

It is common (but not required) for a platform to implement a ConSpliter driver that produces a virtual console device, and this is the console that is pointed to by the EFI System Table. So the ConSpliter redirects the console output to multiple physical console devices. An example would be redirecting the output to a graphics card and a serial port at the same time.
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/Universal/Console/ConSplitterDxe/

Post by Michael Chang
"Driver #32 will install a ConOut device GUID on the handle if the
device path is listed in the ConOut global EFI variable ..."
"EFI uses these three protocols (ConIn, ConOut, and ErrOut) to mark
devices in the system, which have been selected by the user as ConIn,
ConOut, and StdErr. These protocols are actually just a GUID without
any services or data."
On my UEFI desktop "dh -p ConOut" reveals the handles.
I interested in this topic is becasue I want to leverage this protocol
to judge the correct handle if there are more than one handle provides
GOP protocol. For example, elilo simply picks the first located device
handle with GOP and use it, however in some circumstance it leads to a
garbled screen due to the handle is not associated with the real
physical output device.

Bad idea as they are part of an implementation, and not part of the spec.

Post by Michael Chang
But I am now afarid that since this protocol is not in specifcation,
it would not be mandatory for drivers to install it and may need to
figure out other way to circumvant it (or anyone has good suggestion
to judge the correct handle to use for GOP mode information during
boot? )

Best thing to do is to use the ConOut variable. It will be a single or multi instance device path that represents the current console output devices. So in our example above there would be a device path for the graphics card, and a device path for the serial device. Note there could be multiple GOP devices listed, not sure if you plan to support that.

So basically you have a loop to extract device paths out of the ConOut variable, and for each device path you use the LocateDevicePath() boot service to find the handle that contains the GOP. You then use HandleProtocol() to get a pointer to the GOP so you can access the frame buffer info.

The edk2 has BSD licensed device path library functions that you may find useful, like GetNextDevicePathInstance ()
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.c

Thanks,

Andrew

Post by Michael Chang
Thanks,
Michael
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Mcdaniel, Daryl

2012-06-02 00:34:52 UTC

Permalink

There are three entries in the UEFI System Table: ConIn, ConOut, and StdErr.
According to the UEFI 2.3.1-B specification:
ConIn is "A pointer to the EFI_SIMPLE_TEXT_INPUT_PROTOCOL interface that is associated with ConsoleInHandle."
ConOut is "A pointer to the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL interface that is associated with ConsoleOutHandle."
StdErr is "A pointer to the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL interface that is associated with StandardErrorHandle."

If all you want is to capture text input and to send text output, these pointers may be sufficient for you. Both the EFI_SIMPLE_TEXT_INPUT_PROTOCOL and EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL protocols are described in chapter "11 Protocols - Console Support".

Using EDK II's "UefiBootServicesTableLib", displaying text can be as simple as:
gST->ConOut->OutputString(gST->ConOut, L"String to display.\n");

Of course, you would want to add some sort of error handling and possibly optimize the repeated use of (gST->ConOut). I didn't do that here for clarity.

Daryl McDaniel

"Software is like entropy.
It is difficult to grasp, weighs nothing, and obeys the second law of thermodynamics;
i.e. it always increases."
-- Norman R. Augustine

-----Original Message-----
From: Andrew Fish [mailto:***@apple.com]
Sent: Friday, June 01, 2012 9:23 AM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] ConOut Protocol

Bad idea as they are part of an implementation, and not part of the spec.

Michael Chang

2012-06-04 05:05:57 UTC

Permalink

Post by Andrew Fish

These protocols are part part of an implementation of the platforms console splitter and not part of the specification.
It is common (but not required) for a platform to implement a ConSpliter driver that produces a virtual console device, and this is the console that is pointed to by the EFI System Table. So the ConSpliter redirects the console output to multiple physical console devices. An example would be redirecting the output to a graphics card and a serial port at the same time.
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/Universal/Console/ConSplitterDxe/

Thanks to point me this. Yeah I think the cause of the problem is
related with this virtual device created by ConSpliter driver (Thanks
to the document, I couldn't figure out what this virtual device come
from and usage before and now I learned that :)). It possesses GOP
protocol as well and the mode info is not identical with physical one
in use. In the case it is stride (PixelPerLine) property, the virtual
device GOP says 1366 but the physical device handle uses 1376.

The Elilo picks 1366 instead of 1376 as it has no way to distinguish
that and writes to linux kernel header. When kernel boots up the efifb
(EFI firmware framebuffer driver) would set mode according to what
kernel header instructs it and then screen garbled because of stride
not correct ..

Could this be a bug of UEFI firmware ? Suppose that the retrieved info
should be identical with the on physical device in use. Or still it's
up to the EFI application or bootloader's responsibility to locate and
use the physical's one handle (ie .. not trust the GOP info in the
virtual device. ).

Post by Andrew Fish

Bad idea as they are part of an implementation, and not part of the spec.

Maybe to know the GOP of phyiscal device handle that console device in
use is sufficient.

Post by Andrew Fish
So basically you have a loop to extract device paths out of the ConOut variable, and for each device path you use the LocateDevicePath() boot service to find the handle that contains the GOP. You then use HandleProtocol() to get a pointer to the GOP so you can access the frame buffer info.

I did try the LocateDevicePath on the ConOut variable to find the
handle contains GOP, but failed because the handle in interest is
"child" device path of what ConOut variable contains. I need some way
to manipulate the child/parent handles and looked at EDK2's source to
get some idea(like devtree), and finally give up the idea because I
found the needed boot service for manipulating that is absent in
gnu-efi which elilo relies on for interacting efi firmware.

Post by Andrew Fish
The edk2 has BSD licensed device path library functions that you may find useful, like GetNextDevicePathInstance ()

Yeah. I'll give EDK2 a try. I found that gnu-efi is good, but lacks
many new boot service and handy libs in EDK2 (Maybe I am wrong,
because gnu-efi version in the distro I'm working is not latest). To
have EDK2 be wider or easier adopted in linux distribution, we have to
package it and somehow have to circumvent it's build infrastructure to
be able to packaged and distributed (in general an approach like make.
make install). It's now working in progress.

Post by Andrew Fish
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.c

Thanks,
Michael

Post by Andrew Fish
Thanks,
Andrew

Li, Elvin

2012-06-04 05:44:39 UTC

Permalink

Hi:
Consplitter GOP protocol is constructed from real physical GOP protocol on video devices. When there is only 1 video device in system, the mode in Consplitter GOP protocol is this video device mode, if there are more than 1 video devices in system, the mode in Consplitter GOP protocol are intersection of all video devices modes. You mentioned in the case it is stride (PixelPerLine) property, the virtual device GOP says 1366 but the physical device handle uses 1376. It is strange to me. You could check ConSplitterAddGraphicsOutputMode (), it creates GOP modes for Consplitter, for the first video devices, it uses "CopyMem (CurrentGraphicsOutputMode->Info, GraphicsOutput->Mode->Info, GraphicsOutput->Mode->SizeOfInfo);" to creates the first mode, in this code, what is the value of PixelsPerScanLine in your case?

Thanks
Elvin
-----Original Message-----
From: Michael Chang [mailto:***@suse.com]
Sent: Monday, June 04, 2012 1:06 PM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] ConOut Protocol

Post by Andrew Fish

These protocols are part part of an implementation of the platforms console splitter and not part of the specification.
It is common (but not required) for a platform to implement a ConSpliter driver that produces a virtual console device, and this is the console that is pointed to by the EFI System Table. So the ConSpliter redirects the console output to multiple physical console devices. An example would be redirecting the output to a graphics card and a serial port at the same time.
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/
Universal/Console/ConSplitterDxe/

Thanks to point me this. Yeah I think the cause of the problem is related with this virtual device created by ConSpliter driver (Thanks to the document, I couldn't figure out what this virtual device come from and usage before and now I learned that :)). It possesses GOP protocol as well and the mode info is not identical with physical one in use. In the case it is stride (PixelPerLine) property, the virtual device GOP says 1366 but the physical device handle uses 1376.

The Elilo picks 1366 instead of 1376 as it has no way to distinguish that and writes to linux kernel header. When kernel boots up the efifb (EFI firmware framebuffer driver) would set mode according to what kernel header instructs it and then screen garbled because of stride not correct ..

Could this be a bug of UEFI firmware ? Suppose that the retrieved info should be identical with the on physical device in use. Or still it's up to the EFI application or bootloader's responsibility to locate and use the physical's one handle (ie .. not trust the GOP info in the virtual device. ).

Post by Andrew Fish

Post by Michael Chang
"Driver #32 will install a ConOut device GUID on the handle if the
device path is listed in the ConOut global EFI variable ..."
"EFI uses these three protocols (ConIn, ConOut, and ErrOut) to mark
devices in the system, which have been selected by the user as ConIn,
ConOut, and StdErr. These protocols are actually just a GUID without
any services or data."
On my UEFI desktop "dh -p ConOut" reveals the handles.
I interested in this topic is becasue I want to leverage this
protocol to judge the correct handle if there are more than one
handle provides GOP protocol. For example, elilo simply picks the
first located device handle with GOP and use it, however in some
circumstance it leads to a garbled screen due to the handle is not
associated with the real physical output device.

Bad idea as they are part of an implementation, and not part of the spec.

Maybe to know the GOP of phyiscal device handle that console device in use is sufficient.

I did try the LocateDevicePath on the ConOut variable to find the handle contains GOP, but failed because the handle in interest is "child" device path of what ConOut variable contains. I need some way to manipulate the child/parent handles and looked at EDK2's source to get some idea(like devtree), and finally give up the idea because I found the needed boot service for manipulating that is absent in gnu-efi which elilo relies on for interacting efi firmware.

Post by Andrew Fish
The edk2 has BSD licensed device path library functions that you may
find useful, like GetNextDevicePathInstance ()

Yeah. I'll give EDK2 a try. I found that gnu-efi is good, but lacks many new boot service and handy libs in EDK2 (Maybe I am wrong, because gnu-efi version in the distro I'm working is not latest). To have EDK2 be wider or easier adopted in linux distribution, we have to package it and somehow have to circumvent it's build infrastructure to be able to packaged and distributed (in general an approach like make.
make install). It's now working in progress.

Post by Andrew Fish
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Librar
y/UefiDevicePathLib/UefiDevicePathLib.c

Thanks,
Michael

Post by Andrew Fish
Thanks,
Andrew

Post by Michael Chang
Thanks,
Michael
---------------------------------------------------------------------
---------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the
latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Michael Chang

2012-06-04 07:15:02 UTC

Permalink

Post by Li, Elvin
Consplitter GOP protocol is constructed from real physical GOP protocol on video devices. When there is only 1 video device in system, the mode in Consplitter GOP protocol is this video device mode, if there are more than 1 video devices in system, the mode in Consplitter GOP protocol are intersection of all video devices modes. You mentioned in the case it is stride (PixelPerLine) property, the virtual device GOP says 1366 but the physical device handle uses 1376. It is strange to me. You could check ConSplitterAddGraphicsOutputMode (), it creates GOP modes for Consplitter, for the first video devices, it uses "CopyMem (CurrentGraphicsOutputMode->Info, GraphicsOutput->Mode->Info, GraphicsOutput->Mode->SizeOfInfo);" to creates the first mode, in this code, what is the value of PixelsPerScanLine in your case?

FWIW. I paste the output of GOP handles. Note the translated CouOut
variable device path is 'PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)'.

I will check the code pieces you pointed out and get the information
you requested, but since I don't have the source used in the uefi box,
I'm not sure if I could get that if it requires insert debug output
and rebuild.

$ dh -p GraphicsOutput
Handle dump by protocol 'GraphicsOutput'
D5: Txtout GraphicsOutput
146: DevPath (..0x0,0x0)/AcpiAdr(0x80010400))Txtout GraphicsOutput EdidDiscovered EdidActive ConOut

$ dh D5
Handle D5 (BBEEC318)
Txtout (B81E5100) Attrib 7
* mode 0: col 80 row 25
mode 1: error Unsupported

mode 2: col 120 row 36
mode 3: col 128 row 40
mode 4: col 170 row 40
GraphicsOutput (B8401498)
HorizontalReslution 1366
VerticalReslution 768
PixelFormat PixelBlueGreenRedReserved8BitPerColor
PixelsPerScanLine 1366
FrameBufferBase 0xC0000000
FrameBufferSize 0x300000
62BDF38A-E3D5-492C-950C-23A7F66E672E (00000000)
F42F7782-012E-4C12-9956-49F94304F721 (B84014D8

$ dh 146
Handle 146 (BAD65698)
Dpath (BAD65618)
ACPI Device Path for Acpi
HID PNP0A03, UID 0
Hardware Device Path for PCI
Function (0) Device (1)
Hardware Device Path for PCI
Function (0) Device (0)
ACPI Device Path for AcpiAdr
Adr 80010400
AsStr: 'PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010400)'
Txtout (BAE2E330) Attrib 7
* mode 0: col 80 row 25
mode 1: error Unsupported

mode 2: col 120 row 36
mode 3: col 128 row 40
mode 4: col 170 row 40
GraphicsOutput (BC0A7040)
HorizontalReslution 1366
VerticalReslution 768
PixelFormat PixelBlueGreenRedReserved8BitPerColor
PixelsPerScanLine 1376
FrameBufferBase 0xC0000000
FrameBufferSize 0x408000
EdidDiscovered (BC0A71C0)
EdidActive (BC0A71D0)
ConOut (0)

Thanks,
Michael

Post by Li, Elvin
Thanks
Elvin
-----Original Message-----
Sent: Monday, June 04, 2012 1:06 PM
Subject: Re: [edk2] ConOut Protocol

Post by Andrew Fish

These protocols are part part of an implementation of the platforms console splitter and not part of the specification.
It is common (but not required) for a platform to implement a ConSpliter driver that produces a virtual console device, and this is the console that is pointed to by the EFI System Table. So the ConSpliter redirects the console output to multiple physical console devices. An example would be redirecting the output to a graphics card and a serial port at the same time.
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/
Universal/Console/ConSplitterDxe/

Thanks to point me this. Yeah I think the cause of the problem is related with this virtual device created by ConSpliter driver (Thanks to the document, I couldn't figure out what this virtual device come from and usage before and now I learned that :)). It possesses GOP protocol as well and the mode info is not identical with physical one in use. In the case it is stride (PixelPerLine) property, the virtual device GOP says 1366 but the physical device handle uses 1376.
The Elilo picks 1366 instead of 1376 as it has no way to distinguish that and writes to linux kernel header. When kernel boots up the efifb (EFI firmware framebuffer driver) would set mode according to what kernel header instructs it and then screen garbled because of stride not correct ..
Could this be a bug of UEFI firmware ? Suppose that the retrieved info should be identical with the on physical device in use. Or still it's up to the EFI application or bootloader's responsibility to locate and use the physical's one handle (ie .. not trust the GOP info in the virtual device. ).

Post by Andrew Fish

Post by Michael Chang
"Driver #32 will install a ConOut device GUID on the handle if the
device path is listed in the ConOut global EFI variable ..."
"EFI uses these three protocols (ConIn, ConOut, and ErrOut) to mark
devices in the system, which have been selected by the user as ConIn,
ConOut, and StdErr. These protocols are actually just a GUID without
any services or data."
On my UEFI desktop "dh -p ConOut" reveals the handles.
I interested in this topic is becasue I want to leverage this
protocol to judge the correct handle if there are more than one
handle provides GOP protocol. For example, elilo simply picks the
first located device handle with GOP and use it, however in some
circumstance it leads to a garbled screen due to the handle is not
associated with the real physical output device.

Bad idea as they are part of an implementation, and not part of the spec.

Maybe to know the GOP of phyiscal device handle that console device in use is sufficient.

I did try the LocateDevicePath on the ConOut variable to find the handle contains GOP, but failed because the handle in interest is "child" device path of what ConOut variable contains. I need some way to manipulate the child/parent handles and looked at EDK2's source to get some idea(like devtree), and finally give up the idea because I found the needed boot service for manipulating that is absent in gnu-efi which elilo relies on for interacting efi firmware.

Post by Andrew Fish
The edk2 has BSD licensed device path library functions that you may
find useful, like GetNextDevicePathInstance ()

Yeah. I'll give EDK2 a try. I found that gnu-efi is good, but lacks many new boot service and handy libs in EDK2 (Maybe I am wrong, because gnu-efi version in the distro I'm working is not latest). To have EDK2 be wider or easier adopted in linux distribution, we have to package it and somehow have to circumvent it's build infrastructure to be able to packaged and distributed (in general an approach like make.
make install). It's now working in progress.

Post by Andrew Fish
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Librar
y/UefiDevicePathLib/UefiDevicePathLib.c

Thanks,
Michael

Post by Andrew Fish
Thanks,
Andrew

Post by Michael Chang
Thanks,
Michael
---------------------------------------------------------------------
---------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the
latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Michael Chang
Software Engineer
Rm. B, 26F, No.216, Tun Hwa S. Rd., Sec.2
Taipei 106, Taiwan, R.O.C
+886223760030
***@suse.com
SUSE

Li, Elvin

2012-06-04 07:54:05 UTC

Permalink

Hi Chang:

Michael Chang

2012-06-06 04:38:05 UTC

Permalink

Elvin,

Thanks for your analysis and the information. I would have to check
with the vendor of the firmware about the issue (forwarded most of the
message here to them) and no feedback yet. Maybe their release version
based on certain branch that is not merged with new fixes or something
like that.

Would it be possible to diagnose a bit in the shell? For example to
restart the consplitter driver, I tried reconnect the controller
device of video adapter but not useful. Also there's a Graphics
Console driver that seems to be in charge of setting modes for
graphic console, not sure if it has to be a factor to the problem.

Thanks,
Michael

Michael Chang [mailto:]=20

1970-01-01 00:00:00 UTC

Permalink

Thanks
Elvin

-----Original Message-----
From: Michael Chang [mailto:***@suse.com]=20
Sent: Monday, June 04, 2012 3:15 PM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] ConOut Protocol

Consplitter GOP protocol is constructed from real physical GOP protocol =

on video devices. When there is only 1 video device in system, the mode in =
Consplitter GOP protocol is this video device mode, if there are more than =
1 video devices in system, the mode in Consplitter GOP protocol are interse=
ction of all video devices modes. You mentioned in the case it is stride (P=
ixelPerLine) property, the virtual device GOP says 1366 but the physical de=
vice handle uses 1376. It is strange to me. You could check ConSplitterAddG=
raphicsOutputMode (), it creates GOP modes for Consplitter, for the first v=
ideo devices, it uses "CopyMem (CurrentGraphicsOutputMode->Info, GraphicsOu=
tput->Mode->Info, GraphicsOutput->Mode->SizeOfInfo);" to creates the first =
mode, in this code, what is the value of PixelsPerScanLine in your case?

FWIW. I paste the output of GOP handles. Note the translated CouOut variabl=
e device path is 'PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)'.

I will check the code pieces you pointed out and get the information you re=
quested, but since I don't have the source used in the uefi box, I'm not su=
re if I could get that if it requires insert debug output and rebuild.

$ dh -p GraphicsOutput
Handle dump by protocol 'GraphicsOutput'
D5: Txtout GraphicsOutput
146: DevPath (..0x0,0x0)/AcpiAdr(0x80010400))Txtout GraphicsOutput EdidDis=
covered EdidActive ConOut=20

$ dh D5
Handle D5 (BBEEC318)
Txtout (B81E5100) Attrib 7
* mode 0: col 80 row 25
mode 1: error Unsupported

mode 2: col 120 row 36
mode 3: col 128 row 40
mode 4: col 170 row 40
GraphicsOutput (B8401498)=20
HorizontalReslution 1366
VerticalReslution 768
PixelFormat PixelBlueGreenRedReserved8BitPerColor
PixelsPerScanLine 1366
FrameBufferBase 0xC0000000
FrameBufferSize 0x300000
62BDF38A-E3D5-492C-950C-23A7F66E672E (00000000)
F42F7782-012E-4C12-9956-49F94304F721 (B84014D8

$ dh 146
Handle 146 (BAD65698)
Dpath (BAD65618)=20
ACPI Device Path for Acpi
HID PNP0A03, UID 0
Hardware Device Path for PCI
Function (0) Device (1)
Hardware Device Path for PCI
Function (0) Device (0)
ACPI Device Path for AcpiAdr
Adr 80010400
AsStr: 'PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010400)'
Txtout (BAE2E330) Attrib 7
* mode 0: col 80 row 25
mode 1: error Unsupported

mode 2: col 120 row 36
mode 3: col 128 row 40
mode 4: col 170 row 40
GraphicsOutput (BC0A7040)=20
HorizontalReslution 1366
VerticalReslution 768
PixelFormat PixelBlueGreenRedReserved8BitPerColor
PixelsPerScanLine 1376
FrameBufferBase 0xC0000000
FrameBufferSize 0x408000
EdidDiscovered (BC0A71C0)=20
EdidActive (BC0A71D0)=20
ConOut (0)=20

Thanks,
Michael

=20
Thanks
Elvin
-----Original Message-----
Sent: Monday, June 04, 2012 1:06 PM
Subject: Re: [edk2] ConOut Protocol
=20

Hi,
In UEFI spec, it mentioned about the ConOut global UEFI variable is=20
the device path (EFI_DEVICE_PATH_PROTOCOL) of default output=20
console, but seems don't have description on ConOut protocol, which=20
I could only find on EFI 1.10 Driver Writer's Guide

These protocols are part part of an implementation of the platforms con=

sole splitter and not part of the specification.

It is common (but not required) for a platform to implement a ConSplite=

r driver that produces a virtual console device, and this is the console th=
at is pointed to by the EFI System Table. So the ConSpliter redirects the c=
onsole output to multiple physical console devices. An example would be red=
irecting the output to a graphics card and a serial port at the same time.

https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePk
g/
Universal/Console/ConSplitterDxe/

=20
Thanks to point me this. Yeah I think the cause of the problem is related=

with this virtual device created by ConSpliter driver (Thanks to the docum=
ent, I couldn't figure out what this virtual device come from and usage bef=
ore and now I learned that :)). It possesses GOP protocol as well and the m=
ode info is not identical with physical one in use. In the case it is strid=
e (PixelPerLine) property, the virtual device GOP says 1366 but the physica=
l device handle uses 1376.

=20
The Elilo picks 1366 instead of 1376 as it has no way to distinguish that=

and writes to linux kernel header. When kernel boots up the efifb (EFI fir=
mware framebuffer driver) would set mode according to what kernel header in=
structs it and then screen garbled because of stride not correct ..

=20
Could this be a bug of UEFI firmware ? Suppose that the retrieved info sh=

ould be identical with the on physical device in use. Or still it's up to t=
he EFI application or bootloader's responsibility to locate and use the phy=
sical's one handle (ie .. not trust the GOP info in the virtual device. ).

=20

"Driver #32 will install a ConOut device GUID on the handle if the=20
device path is listed in the ConOut global EFI variable ..."
"EFI uses these three protocols (ConIn, ConOut, and ErrOut) to mark=20
devices in the system, which have been selected by the user as=20
ConIn, ConOut, and StdErr. These protocols are actually just a GUID=20
without any services or data."
On my UEFI desktop "dh -p ConOut" reveals the handles.
I interested in this topic is becasue I want to leverage this=20
protocol to judge the correct handle if there are more than one=20
handle provides GOP protocol. For example, elilo simply picks the=20
first located device handle with GOP and use it, however in some=20
circumstance it leads to a garbled screen due to the handle is not=20
associated with the real physical output device.

Bad idea as they are part of an implementation, and not part of the spe=

But I am now afarid that since this protocol is not in=20
specifcation, it would not be mandatory for drivers to install it=20
and may need to figure out other way to circumvant it (or anyone=20
has good suggestion to judge the correct handle to use for GOP mode=20
information during boot? )

Best thing to do is to use the ConOut variable. It will be a single or =

multi instance device path that represents the current console output devic=
es. So in our example above there would be a device path for the graphics c=
ard, and a device path for the serial device. Note there could be multiple =
GOP devices listed, not sure if you =A0plan to support that.

=20
Maybe to know the GOP of phyiscal device handle that console device in us=

e is sufficient.

=20

So basically you have a loop to extract device paths out of the ConOut =

variable, and for each device path you use the LocateDevicePath() boot serv=
ice to find the handle that contains the GOP. =A0You then use HandleProtoco=
l() to get a pointer to the GOP so you can access the frame buffer info.

=20
I did try the LocateDevicePath on the ConOut variable to find the handle =

contains GOP, but failed because the handle in interest is "child" device p=
ath of what ConOut variable contains. I need some way to manipulate the chi=
ld/parent handles and looked at EDK2's source to get some idea(like devtree=
), and finally give up the idea because I found the needed boot service for=
manipulating that is absent in gnu-efi which elilo relies on for interacti=
ng efi firmware.

=20

The edk2 has BSD =A0licensed device path library functions that you=20
may find useful, like GetNextDevicePathInstance ()

=20
Yeah. I'll give EDK2 a try. I found that gnu-efi is good, but lacks many =

new boot service and handy libs in EDK2 (Maybe I am wrong, because gnu-efi =
version in the distro I'm working is not latest). To have EDK2 be wider or =
easier adopted in linux distribution, we have to package it and somehow hav=
e to circumvent it's build infrastructure to be able to packaged and distri=
buted (in general an approach like make.

make install). It's now working in progress.
=20

https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Libr
ar y/UefiDevicePathLib/UefiDevicePathLib.c

=20
Thanks,
Michael
=20

Thanks,
Andrew

Thanks,
Michael
-------------------------------------------------------------------
--
---------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and=20
threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the=20
latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

=20
----------------------------------------------------------------------
--------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and=20
threat landscape has changed and how IT managers can respond.=20
Discussions will include endpoint security, mobile security and the=20
latest in malware threats.=20
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
=20
----------------------------------------------------------------------
--------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and=20
threat landscape has changed and how IT managers can respond.=20
Discussions will include endpoint security, mobile security and the=20
latest in malware threats.=20
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Michael Chang
Software Engineer
Rm. B, 26F, No.216, Tun Hwa S. Rd., Sec.2 Taipei 106, Taiwan, R.O.C
+886223760030
***@suse.com
SUSE

---------------------------------------------------------------------------=
---
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat la=
ndscape has changed and how IT managers can respond. Discussions will inclu=
de endpoint security, mobile security and the latest in malware threats. ht=
tp://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/