• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - demetrioussharpe

#1
Hardware / Re: OpenGL ddk
2011.09.21, 09:33:35
Hello all,

It's been a long time since I've said anything & I feel that it's been quite long enough. There's no good way to say this, so I'll just say it. I'm getting a bit tired of certain aspects of GL/2. Working solo slows things down a bit & is wearing on me. There's only so much that one guy can do. Also, I see how many of the OS/2 community can be resistant to change. On top of all of this, the fact of the matter is that everyone is constrained by the limitations of the horribly aged OS/2 kernel. With that in mind, the following changes will be implemented:

1). I'm scrapping everything in GL/2 except the PGL layer.
2). I'm going to look at how the Mesa3d guys were able to get it to build under VisualStudio & apply that method to getting the same to work for OpenWatcom.
3). I'm going to write my AGP drivers to the specifications expected by the SNAP driver framework.
4). I'm going to dig through the source code to the WarpMesaGL port & try to understand how the author was able to tie Mesa3d to the GRADD API & try to do the same while attempting to shoe-horn Gallium3d into it all.
5). I'm going to graft my PGL layer on top of the SNAP mgl system (yes, I have the SNAP sdk/ddk).
6). I'm going to replace Mesa3d 4.1 that in the SNAP 3d ddk with a more modern version that used Gallium3d.

All of this should amount to a pretty modern & robust 3d stack that's achievable in a much shorter time-span than the roadmap that I was originally working towards. Couple that with the fact that Mensys now has the source to SNAP for OS/2 & you end up with a situation where everything ties into each other, because SNAP will be automatically included in eCS when they finish doing whatever they're going to do for integration purposes. It is very likely that I won't do much more in this area for this community after this work is complete. There's simply too few OS/2 developers & I really don't see a real reason to move to another big project without a real developer support system.

Just wanted to let everyone know what's going on & that I'm still at work. As time permits, I'll update the docs in the repo to reflect the changes.
#2
Hardware / Re: OpenGL ddk
2011.07.18, 06:11:31
Quote from: miturbide on 2011.07.18, 06:01:38
I wish you all my best Demetrius !!

Thanks a lot! I've registered for warpstock & I'll be giving a presentation over what exactly GL/2 is. There's nothing to show visually, though.
#3
Open Bounties / Re: OS2 & eCS kernel
2011.07.18, 02:23:00
Quote from: Ben on 2011.07.17, 22:33:35

I'm sorry to learn about your medical problems.

I hope that they are short-lived and leave without a trace.



Thank you. Unfortunately, I now have to learn how to live as a diabetic & how to drop my triglyceride levels. Apparently, I can't escape genetics...
#4
Open Bounties / Re: OS2 & eCS kernel
2011.07.17, 22:15:10
Sorry it's been awhile. I haven't been able to work on any kernel work because of a combination of preparing to move & medical issues. I'm scaling back most of my development efforts & sadly, this is one of the projects that's under the ax right now. Perhaps I'll return to this project once I'm doing better, health-wise.
#5
Hardware / Re: OpenGL ddk
2011.07.17, 22:13:07
Sorry it's been awhile. I haven't been able to work on GL/2 because of a combination of preparing to move & medical issues. Development won't continue until after the 1st of August. This will give me time to settle into the new house & put my office back together. More to follow.
#6
Hardware / Re: Multi-monitor Systems
2011.05.31, 00:11:50
Quote from: jep on 2011.05.30, 09:49:00
Yes, I guess it would be a bit of a challenge to create something like that on top of everything else.

Yeh, it really would complicate things vastly. Afterall, I'm new to a lot of this.


Quote
Another interesting feature would be to set/switch which monitor should act as No 1 and the next as No 2 etc to allow e.g. laptops to use a large external monitor as the primary display
Several of our developers where I work use that feature when they're sitting in the office.

Quite honestly, that's one of my next few blocks of code to work on. Though, I had different motivations for it, I wanted to be able to change the order of framebuffer outputs. In addition to the usage case that you just touched on, it would also allow you to setup a multitude of monitors & decide the order that they are in. This would be beneficial when you take into consideration a 3x2 or 3x3 display setup. You'd want the final desktop image to be in the correct order, so you'd want to be able to configure the output regardless of the actual physical layout of the monitors.
#7
Hardware / Re: Multi-monitor Systems
2011.05.28, 23:01:27
Quote from: jep on 2011.05.28, 09:37:54
Hello,

the first two images show how pointer movement between two screens can be handled.
It's very confusing if the pointer doesn't appear on the second screen right next to the exit point from the first screen.

The rest of the images show a few 3D-CAD images that I modeled some time ago.

Missing images:
CRT Monitor
Monitor and projector
Monitor and TV
Monitor and Laptop
...?

//Jan-Erik

I can't promise that you'll be able use an extended desktop on multi-head setups that use displays without identical resolutions.
#8
Open Bounties / Re: OS2 & eCS kernel
2011.05.27, 02:06:42
Just a heads up. If I understand correctly, 16-bit code won't execute on a 64-bit machine in long 64-bit mode. I'm not sure yet about 32-bit code. But, with that being the case, there's going to be a huge push to create a standard for 64-bit functions, structures, & general data. In short, 64-bit OS/2 will need to be standardized. After soliciting advice from others in the OS/2 community, I was advised to try using elf in 64-bit mode for OS/2-64. Does anyone have an issue with this? Keep in mind, this is a long term project that entails creating the whole software stack from development tools to OS to drivers to APIs to applications. In essence, a brand new operating system & ecosystem. Is there anyone else willing to contribute?
#9
Hardware / Re: Multi-monitor Systems
2011.05.25, 23:21:25
Quote from: RobertM on 2011.05.25, 22:39:07
Quote from: demetrioussharpe on 2011.05.25, 07:22:21
Quote from: RobertM on 2011.05.24, 10:04:25
Question, how do you plan on handling full screen CMDLINE sessions?

Well, my plan is to present the compositor with a virtual framebuffer by using a virtual driver class to communicate with the actual video cards. This will provide enough seperation to allow the rendered output's destination to be changed without disrupting the actual data. By changing the configuration of the virtual framebuffer, the virtual driver can decide which data goes to which screen. Ideally, that should cover the command line sessions that're used as full screen, also. However, I'm sure that there will be quite a few edge cases that'll have to be worked out in order to mature the codebase.

Ummm... wow! If I'm following you correct, that means true full-screen to windowed (or vice versa) switching, simply by reassigning the output. Nice!

Basically, yes. But, as always, the devil is in the details.
#10
Hardware / Re: Multi-monitor Systems
2011.05.25, 17:30:13
Quote from: warpcafe on 2011.05.25, 14:09:52
Hi,

looking at Sigurds scenario, again the solution wouold be to provide a "hookable" function that can be used by the enhancers.
OK, a hotkey will not make sense here because the keyboard isn't accessible. But even then, if someone comes up with a "mous gesture" handler for the enhancers, the function "rotate primary screen" could be assigned a gesture.

The most relevant part here for me is that the driver must be able to handle screen rotations separately for each physical screen.
That's quite some fiddling around the actual core task to have a driver :))

I strongly recommend to think about modularization of the tasks/features:
If one provides API calls to rotate screen(s), clone|extend dekstop, swap screen for a given window these could be made available to the next layer of user applications which would then make them available as mouse gestures, hotkeys or even -heck- launchpad buttons. In any way it saves the driver developer from having to hardcode everything in the first stage with roughly about 98,5% of users complaining that they prefer a different method for ... whatever.

Just my 2ct, cheers,
Thomas

My plan is to put this virtual device within EMIT3D.DLL. It will be the lowest layer within that dll, so it'll talk directly to the video drivers. It's presence should not change anything for the driver writers, because it will communicate to the drivers through the same interface as was already planned for the drivers.
#11
Hardware / Re: Multi-monitor Systems
2011.05.25, 17:26:10
Quote from: Sigurd on 2011.05.25, 13:47:08
Quote from: miturbide on 2011.05.22, 22:23:08
"Monitor orientation - landscape, portrait and the inverse ones"

I meant to have the 4 orientation modes posible. Landscape and Landscape upsidedow. Portrait and portrait upside down. Just like rotating the monitor 90ยบ in the 4 positions that you can..... sorry Im not good explainin it in english.

Other feature to add:

  • Autodetect quantity of monitors

Hi,

it would like to have these feature as well! As you may have seen in my Youtube videos I am using a X200T (Tablet) notebook quite well with OS/2.

With Windows (XP, Vista or 7) there is a function to rotate the Display, as Martin describes. Even though it can use "auto rotation" as well, so it automatically jumps to the view depending in wich way the user moves the Laptop.

There is a hardwarebutton (below the screen) for Rotation availiable as well.

For me I would be very happy to have the possibility to rotate the screen and "by hand" would be really very good.
Auto Rotation is not necessary at all - even if it is quite cool :-)
Having the hardware button working for this would be great as well, because once you switch to tablet mode by Flipping the Screen around -it does lay on the keyboard and covers the keys :-( (You can see this happening almost in the end of my vidoe "The longest death in computer history" at youtube)
With Wim Brul we have been able to use the Stylus as a mouse replacement - and that is really cool by the way - it would be good to have a possibility to change Rotation by having a Mouse command defined so that this could be used with the Stylus.

I am really looking forward to see what will happen with your project. If I can be helpfull in testing "rotation" or something like this - just ask for!

Here a picture with Warp 4 MCP2 and the X200T




Though, I'm not sure what effect my implementation of these features will have on your tablet, I look forward to providing them in the hopes that someone will be able to tie them to the actual hardware within your device.
#12
Hardware / Re: Multi-monitor Systems
2011.05.25, 17:21:26
Quote from: warpcafe on 2011.05.25, 12:14:57
Hi,

Quote from: demetrioussharpe on 2011.05.23, 20:07:26
This is a very interesting idea & I feel that something like this could be considered to be part of the framework; I really like this idea a lot! Is this button positioned on the left side of the maximize/minimize/close button cluster? It ONLY displays on the window that  has focus? Is this button always available, or does it only work on extended desktops or something like that?

Exactly.
That feature becomes available only if the video driver detects that
- there is more than one output device
- the desktop is extended
And then, the button is displayed on "active" titlebars only (meaning only the focused window has it)

However... this dynamic way of showing an additional button only for the focused window isn't mandatory for me - it would be OK to have it also on the "incative" windows (or "all" windows so to say). Not sure which way is easier to imlement.

One glitch however happens with windows that use their own style: While the button displays correctly on all windows that use the default theme currently selected, it overlays the standard button cluster (min|max|resize,close) of e.g. Google Chrome. I've attached a sample screenshot. And the additional button is not really aligned correctly even with the standard window styles... looks pretty much like a window handler "hack" to me.

Note that the feature perhaps is cool, however its implementation into the user interface is a bit... sluggish.
An "elegant" way of implementing this in eCS could be to provide this function in a way that the usual "enahncers" (XWP, eWP, eStyler) can make use of it. Example: "middle-button click on titlebar" or ctrl-doubleclick... or any hotkey combination like shift+ctrl+cursor-left... ;)

Cheers,
Thomas

I'm sure that something can be worked out that'll be less of a visual distraction!
#13
Hardware / Re: Multi-monitor Systems
2011.05.25, 15:36:01
Quote from: warpcafe on 2011.05.25, 11:12:43
Hi,

sounds like a plan. ;) Also this would solve a couple of possible annoyances I came across when thinking about how it would work.
I remember that when I was developing software, one of my usual lines of code went like

Quote"make window become centered horizontally and vertically" - pseudo code:

win.top = int ( ( screen.height - win.height ) / 2 )
win.left = int ( ( screen.width - win.width ) / 2)

I am sure almost every developer has some flavor of this code lying around... and I wonder what the impact will be when this is used, for instance, in a 2-monitor extended desktop setup...? Will the window appear 50% on right margin of left screen and 50% on left margin of right screen then? Will the virtualized driver/framebuffer handle this for the requesting applications automatically? Or is that already covered by the way how OS/2 works?

Feature request: (While we're at it... ;) )
One thing that really drives me nuts with an extended desktop (here: windows) is the following:
- you have 2 screens: A and B
- you launch a program and its window appears on screen A
- you drag the window onto screen B
- now you do something that causes a secondary window of the program to become opened (e.g. "open file" dialog)
-> ta-daa: This "popup" appears on screen A.

The problem is that if you look an the program window on screen B you hardly notice the secondary window at all.
I am not sure if that can be handled in an elegant way so that it becomes "transparent" to applications that they automatically stick to the screen they're currently being displayed upon... would be great though... :-P

Cheers,
Thomas

I don't think it depends so much on the framebuffer, as it most likely depends on how the GUI is designed. In some OSs, the GUI would default to trying to start the window at the top left corner. For some, it's the center of the screen. If these defaults are not wanted, the app designer is usually able to specify where they'd like the window to appear at initially. You may actually be dealing with a product of app designer didn't expect the desktop to ever be so big, so the window always opens in the first screen.
#14
Hardware / Re: Multi-monitor Systems
2011.05.25, 07:22:21
Quote from: RobertM on 2011.05.24, 10:04:25
Question, how do you plan on handling full screen CMDLINE sessions?

Well, my plan is to present the compositor with a virtual framebuffer by using a virtual driver class to communicate with the actual video cards. This will provide enough seperation to allow the rendered output's destination to be changed without disrupting the actual data. By changing the configuration of the virtual framebuffer, the virtual driver can decide which data goes to which screen. Ideally, that should cover the command line sessions that're used as full screen, also. However, I'm sure that there will be quite a few edge cases that'll have to be worked out in order to mature the codebase.
#15
Hardware / Re: Multi-monitor Systems
2011.05.24, 04:47:57
Quote from: RobertM on 2011.05.23, 22:32:52
Not particularly concerned if the current method works. That I am presuming should still be easily achievable by manually resizing the window across viewport. More concerned with (which OS/2 currently doesn't do) constraining a full screen request to a single monitor.

Ok, to be clear, you'd like the capability to make the app maximize, but be confined to just one screen?