GUI is always an huge monster. You must handle graphics, windowing, message, notification and etc. As an IBV, we do have the GUI and also think about how to contribute this to UEFI framework. Yes, HII and VFR is not the GUI, it just utilize the GUI engine for drawing the corresponding widgets. Such like button, scroll bar, dialog box, toggle, on screen keyboard and more. You can refer to this link to see how VFR utilizes GUI core for the user's input and output. https://www.youtube.com/watch?v=LKlScYDltPQ The protocols which provided by the GUI core engine can also be utilized for the UEFI window-like application. Of course, once the protocol becomes a portion of UEFI framework, then each provider can have the implementation for the different look and feel. See below for the UEFI window-like applications. https://www.youtube.com/watch?v=rTqhk82XIts Current UEFI foundation is still lake of the modern GUI support due to it is not specific for the GUI. Such like the timer is not quick enough for handling the rapid event device (USB, touch and etc.). HII font support can just handle bitwise pixel, that is black and white. GOP.BitBlt is always not so fast for the motional graphics on the real platform. The performance of the memory manager (BS.AllocatePage and BS.AllocatePool) is not so good for the frequently memory allocation (GUI must update screen in frequently). We use the alternate ways to approach the above requirements. Besides, once you have the GUI protocol for the end user. How do you provide an easy way to end user for developing the applications. Script language is always the better choice. You don't have to write a bunch of code for creating window, instead you use one line script for it. Form Markup Language was designed for it. See this, https://www.youtube.com/watch?v=SkOYQD7pKg8 Of course, it would be better to use the VFR language as the script language. No matter to use the existing VFR-op or create the new ones. However, as the GUI, you must handle the notifications from the widget. You must send the messages to the widget. Although there is the callback mechanism, it seems to us not enough for the GUI needs. There is another interesting thing to share with you, the virtual UEFI environment. Once you are in the GUI, then why you have to switch to the text mode for the EFI shell. :-) https://www.youtube.com/watch?v=Io7B637Ntts Seems it is still a long way to have the GUI support in UEFI framework. Just share what we done to you. Not the commercial time... :-) Thanks, Abner
-----原始郵件----- 寄件者: [email protected] [mailto:[email protected]] 寄件日期: 2013年3月13日 上午 04:23 收件者: [email protected] 主旨: edk2-devel Digest, Vol 39, Issue 36 Send edk2-devel mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/edk2-devel or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of edk2-devel digest..." Today's Topics: 1. Re: VFR beginner question (Thomas Rognon) 2. Re: Driver dependencies (Andrew Fish) 3. Re: VFR beginner question (Andrew Fish) ---------------------------------------------------------------------- Message: 1 Date: Tue, 12 Mar 2013 15:07:01 -0500 From: Thomas Rognon <[email protected]> Subject: Re: [edk2] VFR beginner question To: [email protected] Message-ID: <CA+jkM630=ukp6hkzyurauagbij56nffyfdkxh5dmjhn0_7v...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" I'm interested in contributing my GUI framework as a edk2 subproject, but I'll have to clear that by my employer first. Also, I've never contributed to an open source project before, so I'm not sure how that process works. On Tue, Mar 12, 2013 at 1:14 PM, Andrew Fish <[email protected]> wrote: > On Mar 12, 2013, at 9:21 AM, Thomas Rognon <[email protected]> wrote: > > I ran into the same issues and, as far as I could find out, UEFI provides > nothing for user interface except the ability to transfer a pixel buffer to > the screen. HII and VFR aren't user interface, they are just underlying > structures that a user interface can be built upon. I ended up writing my > own GUI framework and now I have a nice mouse and buttons and scrollbars > and pretty fonts, but I had to do it all from scratch. I wrote a couple > layout managers to take care of resizing and different screen resolutions. > A constraint layout (google GWT LayoutPanel) and list layout can do almost > any kind of layout you want. I also found very little image support and > ended up writing some tools that convert png and bmp images into source > files that compile into my UEFI application. I've only done one UEFI > application so far, but I built the GUI framework as a driver so it can be > used for other stuff later on. > > Well, that's how I did it. Hope it helps. If anyone knows a better way, > I'm interested also. > > > UEFI does not specify a GUI framework as our thinking was different > vendors might want a different look, and feel. These different look and > feels could imply a different GUI API, or maybe it is just easier to port > an existing framework to UEFI so standardizing the API does not really > help. If you think about it, it makes sense. Some folks may want a Metro > (don't remember new name) look, vs a Windows XP look, vs X11 look, vs a Mac > look, vs a windowless UI look... > > Currently the edk2 does text for Hii since that works everywhere. The GOP > does not run over a serial port for example. > > The reason there is no GUI framework is no one has contributed one. I'm > sure it would be possible to have an edk2 subproject that was a GUI > framework. So feel free to contribute. > > Thanks, > > Andrew Fish > > Thomas Rognon > > > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 2 Date: Tue, 12 Mar 2013 13:16:29 -0700 From: Andrew Fish <[email protected]> Subject: Re: [edk2] Driver dependencies To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Thomas, The edk2 is an example of a UEFI implementation, but many can exist. I think you should read UEFI 2.3.1 (http://www.uefi.org/specs/) section 2.6 to understand what a UEFI system is required to do. I'd also point that something like a Firmware Volume is not UEFI, but PI (UEFI Platform Initialization Specification 1.2.1). A UEFI system is not required to implement PI. Also in the UEFI world some things have gotten obsoleted over time, so there may be a way to fallback to and older version gracefully. If you let the list know some of the protocols you are depending on we may be able to give you some advice on the list. Andrew Fish On Mar 12, 2013, at 1:03 PM, Thomas Rognon <[email protected]> wrote: > I haven't yet come across a computer that has all, or even most, of the > drivers included in edk2. This is a problem because my UEFI application > depends on some of these drivers. > > I need to deploy my application as efi files and not interfere with the > vendor's firmware volumes, so creating my own firmware volumes and replacing > the vendor firmware volumes is not an option. > > My solution is to have copies of all the required drivers for my application > alongside of my application and have a script load them all and then start my > application. > > My problem is finding what drivers are needed and in what order they need to > be loaded. It's been very hit and miss so far. Half of the time, the > drivers won't even load, they will crash the computer (I'm assuming because > they require other drivers to be present first). > > Does anyone know a good way to figure out what drivers are required and in > what order for an arbitrary application? Also, even though most UEFI systems > don't --provide-- all of the edk2 drivers, are all UEFI systems guaranteed to > --support-- all of the edk2 drivers? > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 3 Date: Tue, 12 Mar 2013 13:22:54 -0700 From: Andrew Fish <[email protected]> Subject: Re: [edk2] VFR beginner question To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" On Mar 12, 2013, at 1:07 PM, Thomas Rognon <[email protected]> wrote: > I'm interested in contributing my GUI framework as a edk2 subproject, but > I'll have to clear that by my employer first. Also, I've never contributed > to an open source project before, so I'm not sure how that process works. > The process is here, and you must agree to the TianoCore Contribution Agreement 1.0. https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Contributions.txt The edk2 is all BSD license so folks are not required to give back changes, and we can't accept code that has non-compatible license. So for example if your subproject contained GPL code, or code copied from a GPL project then it would have to have a GPL license and be in its own subproject. Thanks, Andrew Fish > > On Tue, Mar 12, 2013 at 1:14 PM, Andrew Fish <[email protected]> wrote: > On Mar 12, 2013, at 9:21 AM, Thomas Rognon <[email protected]> wrote: > >> I ran into the same issues and, as far as I could find out, UEFI provides >> nothing for user interface except the ability to transfer a pixel buffer to >> the screen. HII and VFR aren't user interface, they are just underlying >> structures that a user interface can be built upon. I ended up writing my >> own GUI framework and now I have a nice mouse and buttons and scrollbars and >> pretty fonts, but I had to do it all from scratch. I wrote a couple layout >> managers to take care of resizing and different screen resolutions. A >> constraint layout (google GWT LayoutPanel) and list layout can do almost any >> kind of layout you want. I also found very little image support and ended >> up writing some tools that convert png and bmp images into source files that >> compile into my UEFI application. I've only done one UEFI application so >> far, but I built the GUI framework as a driver so it can be used for other >> stuff later on. >> >> Well, that's how I did it. Hope it helps. If anyone knows a better way, >> I'm interested also. >> > > UEFI does not specify a GUI framework as our thinking was different vendors > might want a different look, and feel. These different look and feels could > imply a different GUI API, or maybe it is just easier to port an existing > framework to UEFI so standardizing the API does not really help. If you think > about it, it makes sense. Some folks may want a Metro (don't remember new > name) look, vs a Windows XP look, vs X11 look, vs a Mac look, vs a windowless > UI look... > > Currently the edk2 does text for Hii since that works everywhere. The GOP > does not run over a serial port for example. > > The reason there is no GUI framework is no one has contributed one. I'm sure > it would be possible to have an edk2 subproject that was a GUI framework. So > feel free to contribute. > > Thanks, > > Andrew Fish > >> Thomas Rognon >> > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar_______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ------------------------------ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel End of edk2-devel Digest, Vol 39, Issue 36 ****************************************** ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
