headers
James Harr | 1 Mar 04:11

Re: Wiki: Porting window managers


> So far I'm d'accord.  My point is that it wouldn't be good if the
> first bigger release of Y were basically an X emulator, only slower
> and with crappy hardware support.  That probably wouldn't leave the
> impression that we are trying to make.

Who ever said X had to be hardware accelerated? :) It just has to be usable. 
If it is hardware accelerated, it will be by the canvas widget which will 
have acceleration for basic shapes, which is essentially how X works anyway. 
I agree that it would be nice if you could make a QT back end that's a drop 
in replacement, but Mark makes a valid point, make one backend (X) and be 
done with it.

No one ever said we had to support glx in the X emulation either, it'd be 
cool, but not really necessary at 1.0. If someone wants to play quake3 really 
badly they can have a bare installation of x windows and use that if they 
really want to. If everything goes well (and Y has opengl support), game 
makers will start to use Y instead of X for games. But in the mean time, if 
they really need performance in X, they can use X.

We wouldn't make much of an impression at all if we only supported a few real 
apps at release 1.0. Now Y wouldn't be slow and crappy, X would be slow and 
crappy, like it is now. Y would remain fast.
Permalink | Reply | 0 comments |
headers
Erik | 1 Mar 04:53
Picon

Adventures in threading

Woops, accidentally replied directly to Mark, when I meant to send this to the 
mailing list.  Wouldn't want to be accused, by some future SCOundrel, that 
"not all contributions to y-windows were public".

--------------------------------------------------------------------------------------------------

> > Just curious.  I'm trying to decipher the exact process by which the Y
> > window system does its thing (ladder diagrams and all that) in
> > preparation for threading it.
> >
> > Actually, an overview of the main process loop might save me some
> > code-exploring time, but I think I've got the basic idea anyway.
>
> OK.  One Y `iteration' is kicked off by one of:
>

Wow, that's a great overview, my understanding of the system has grown quite a 
bit.  I did notice that interesting "coincidence" that a single select() 
launched each iteration on its own.  It's a great design, very simple.  I'm 
sorry about my plans to complicate it :) Of course it's done in the spirit of 
the hope of specific improvements.

My goal isn't precisely to thread Y, although I do believe that that is the 
best approach to getting it to behave in the way I'm thinking.  What I really 
want to do is, in order of importance:

#1:  Reduce its latency.  I'm defining latency as the maximum amount of time 
that it can take between a user action, done with the expectation of visual 
response, and the visual response.  For example, I move the mouse, the mouse 
pointer tracks my movements.  I click a button, that button changes to the
(Continue reading)

Permalink | Reply | 501 comments |
headers
Erik | 1 Mar 05:23
Picon

Re: Adventures in threading

Okay, quick correction, I misread chapter 6 and the code -- no need to worry 
about refresh rates and so on, the design of Y already takes care of all of 
this naturally...  so this section of what I wrote is moot.

> Another point - as CPU's and GPU's get faster and faster, we run into
> perhaps a more serious problem, where the CPU and GPU are doing more work
> and updates than are useful, thus wasting cycles that could be used on some
> other task. Imagine text in a terminal.  Most terminals have some kind of
> "jump" code in there so that if data comes streaming in too fast to be
> useful, it no longer scrolls on every line or draws every character, but
> rather, does the work in bigger chunks, less often.  But this logic belongs
> naturally in the visual server, in this case Y, because it's Y that stands
> between what the software wants to display and what is actually shown on
> the screen.  It could even be done such that dirty rectangles are merged at
> lower levels and "duplicate regions" are thrown out at each level, before
> propogation, if there still hasn't been a hardware refresh.
Permalink | Reply | 501 comments |
headers
Ben Urban | 1 Mar 07:06
Picon

Re: GUI design docs

On Thu, 2004-02-26 at 03:19, Ben Urban wrote:
> That reminds me of a library for Mac OS 9 called InputSprockets,
> designed primarily for games.  Basically it allowed the program to bind
> actions to various inputs from various devices.
> 
> What I'd like is for input and output devices to be completely
> abstract.  For example, to see an N64 controller (best example I have
> handy) as a device with 10 buttons, 2 axes, and an 8-way digital control
> pad.  If output devices were treated like that too, it could be set up
> so that (for example) two people could play a game where neither one can
> see the other person's screen.  That would be an improvement over most
> console gaming systems! :)
> 
> This would have to be at a very low level, of course.  Probably right
> between the driver and UI levels.
> 
> I would be willing to work on such a task.  In case anyone needs
> clarification, I'll write up some preliminary header files and post them
> to the list.

They can be found at http://znode.org/temp/Y/Y-io-level1.tar.bz2 .

> 
> [snip]
Permalink | Reply | 0 comments |
headers
jartur | 1 Mar 07:00

Re: keyboard layouts (continued)

Maurice van der Pot wrote:
And Alexey Boyko wrote
And many others wrote

But [SNIP Everything]

And:

What if I make the system which will work ? Which will work w/ dvorak, 
qwerty, azerty, kana, kanji, hanji, hangul, devanagari, hebrew 
(right-to-left, btw), arabic, greek polytonic und so weiter...

Note:

I didn't say that I WILL make it :) ! It depends on my sloth :^) ! So 
don't say, 'You said you would make it and you didn't!'

И еще:
Алексей, вы когда пишите в первом лице (I), не надо
добавлять -s к 
глаголу (e.g. I make-s, а надо I make), это действительно только
для 
третьего лица единственного числа (he/she/it).

--

-- 
iiartvrvs pavlenicvs agnitor sacer obscvrvs
http://zhurnal.lib.ru/a/aaronow_a_a

#___#___####___#_____#___#
#___#___#__#___#____#____#
(Continue reading)

Permalink | Reply | 2 comments |
headers
jartur | 1 Mar 07:12

Re: keyboard layouts (continued)

Hmm.. But just one question:

Can you all finally decide _what_ will handle the keyboard and work w/
keymappings and keyboard layouts ? What will take switching of layouts ?
What will take menus/hints for hanji/kanji/kana/hangul/et cetera.  Y ?
KB driver ? Applications themselves ?

--

-- 
iiartvrvs pavlenicvs agnitor sacer obscvrvs
http://zhurnal.lib.ru/a/aaronow_a_a

#___#___####___#_____#___#
#___#___#__#___#____#____#
#___#______#___#___#____#
#___#______#___#_#_____#
#___########___########
#
#
Permalink | Reply | 1 comment |
headers
Chris Amshey | 1 Mar 07:37

Re: [PATCH] Y logging into wrong log

On Sun, Feb 29, 2004 at 11:34:09PM +0100, red_alert wrote:
> yea, it's working for me.
> 
> my syslog.conf (as far as i remember, i didn't change anything manually):
> 
> # Save boot messages also to boot.log
> local7.*                                                /var/log/boot.log
> 
> regards
That's the culprit then. Everything else looks reasonably standard,
but this is what I'd call a 'red hat specific problem', but still, redhat
being such a broad base I think I recommend this patch be applied against
markbt's tree (or mark can make the 1-character change himself to the
local of his choice. :))
Permalink | Reply | 0 comments |
headers
Chris Amshey | 1 Mar 08:00

Re: keyboard layouts (continued)

On Sun, Feb 29, 2004 at 02:39:21PM -0500, Bryce Nichols wrote:
> Oh, and I have this binary keyboard that has only 2 keys.  I need a way to
> enter the equivalent of CAPS-LOCK, so I don't have to type an extra bit
> for setting the case of letters each time.
> 
> - --Bryce
This may or may not be entirely a silly point... certainly the 
robotics lab people would be happy about this, since it would reduce
the effort of creating a good heads-up display on their cyberglasses
controlled with their twiddle-inputs... 

Perhaps more likely to see widespread use and less able to hack code
themselves, in the accessibility universe we do actually have some
exceedingly limited input methods available in certain cases (like
eyeblink-readers), but of course the less extreme the condition the
less likely a research grant for such a thing will get you tens of 
thousands of dollars of free, if experimental, hardware. 

Plus, in the future, limited-input may come with wearable computing, if
wearable computing actually becomes any kind of reality. I expect voice
recognition will be preferred, but it may not always be an option, and
someone may yet come up with one of these twiddly, chording thingies that
people outside of MIT are actually willing to use. 

All these kinds of things can be handled as special cases and modules, of
course, so I wouldn't go out of your way to include them, but if generalizing
to allow the possibility of strange input devices is easy, I'd do it.

(thinking about it, actually, it may well make a lot more sense to
have a different lowest-level handler for such a thing as a chording
(Continue reading)

Permalink | Reply | 0 comments |
headers
JP Dinger | 1 Mar 11:45
Picon
Picon

Re: keyboard layouts (continued)

On Sun, Feb 29, 2004 at 07:47:41PM +0100, Maurice van der Pot wrote:
> On Sun, Feb 29, 2004 at 01:38:20PM -0500, Bryce Nichols wrote:
> > In fact, it should be possible for a modifier to be
> > activated by a key sequence rather than a single key press. 
> 
> This is a new requirement; I haven't seen this on the list before.
> Would we want a modifier to be implemented as a key sequence instead
> of a single key?

Do you have to? I can imagine (ab)using a few of the 32 (or 64) modifiers
to implement a state machine for those that really want that.

Ok, so it's not as general as full tree support, and it reeks a bit, but;
I think this is a not very much used construct and a hack will fit its
perceived usage pattern better than full tree support.

> But I would like to see the use of this. Do you have a good example
> of how this could be useful? (Please don't give the example of having
> meta-modifiers ;) )

<aol/>, I'm intrigued how one'd want to use this.

--

-- 
  j p d (at) d s b (dot) t u d e l f t (dot) n l .
Permalink | Reply | 0 comments |
headers
Rupert Mazzucco | 1 Mar 14:45
Picon
Picon

Re: keyboard layouts (continued)

On Mon, 1 Mar 2004, Maurice van der Pot wrote:

> Take a look at this: http://www.linuxjournal.com/article.php?sid=1080

Thanks, it's interesting reading, but about the old driver.  As far as I
understand it, this has been obsoleted by the new input driver.

> X gets its raw scan codes by setting a mode of the device. We shouldn't
> do that because it requires root privileges (and that's just one reason),

I strongly advocate using the proper kernel devices (ie drivers) and not
mess around with direct hardware access.  That might have been necessary
for X way back then, but nowadays the appropriate response to "it doesn't
work with my hardware" is IMHO "then get your vendor to release a driver
for Linux/BSD/whatever".  It also makes our job easier.  After all, Y is
supposed to be a layer that uses the kernel, not a partial kernel replacement.

The same goes, btw, for access to the graphics card.  We should, in the
case of Linux, rely on fb and maybe the drm module and not try to program
our own drivers.

> from key codes. I don't know if the linux kernel still just passes on
> the scan codes as key codes without conversion, like it used to.

You can still set it with kbd_mode, at least.  But it really uses the
input driver internally.  Last entry in the keyboard.c preamble:

 * 21-08-02: Converted to input API, major cleanup. (Vojtech Pavlik)

Regards,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane